From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7086 invoked by alias); 16 Feb 2004 16:21:28 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 7069 invoked from network); 16 Feb 2004 16:21:28 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 16 Feb 2004 16:21:28 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id 0F4221A448A; Mon, 16 Feb 2004 11:17:17 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16432.60685.971975.226931@localhost.redhat.com> Date: Mon, 16 Feb 2004 16:21:00 -0000 To: gdb-patches@sources.redhat.com Subject: Re: [RFA] sh-tdep.c: optimize fv_reg_base_num and dr_reg_base_num In-Reply-To: <20040216160002.GJ18953@cygbert.vinschen.de> References: <20040211151544.GT4162@cygbert.vinschen.de> <16432.57749.894105.453337@localhost.redhat.com> <20040216160002.GJ18953@cygbert.vinschen.de> X-SW-Source: 2004-02/txt/msg00410.txt.bz2 Corinna Vinschen writes: > On Feb 16 10:28, Elena Zannoni wrote: > > Corinna Vinschen writes: > > > Hi, > > > > > > another optimization which also will simplify the handling of the > > > upcoming SH variant. > > > > > > The functions fv_reg_base_num and dr_reg_base_num are basically > > > one-liner. The expression they evaluate is fairly simple so > > > I'd suggest the following patch. It converts both functions > > > into macros which will be evaluated inline. This has the additional > > > advantage, that the functions in which they are called have access > > > to gdbarch, which comes in handy for the new SH variant. > > > > > > If the conversion into macros is undesired, I'd like to suggest an > > > alternative implementation. In that case I'd like to add gdbarch as > > > first parameter to both functions. > > > > I prefer to not introduce macros here. Can you explain where you are > > headed? This looks like a micro optimization and I don't see the point > > of it ATM. > > Gosh, I'm so sorry. I should have cancled this RFA already days ago. > This is a result of the same thinko I talked about in my previous > mail. The (blockheaded) idea was to use another SH_NUM_REGS for the > new CPU variant than for any other SH type. I already scratched that > but I missed to note that here :-( Ok, I'll ignore this patch then.