From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29728 invoked by alias); 16 Feb 2004 15:32:34 -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 29707 invoked from network); 16 Feb 2004 15:32:33 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 16 Feb 2004 15:32:33 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id EEF011A448A; Mon, 16 Feb 2004 10:28:21 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16432.57749.894105.453337@localhost.redhat.com> Date: Mon, 16 Feb 2004 15:32: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: <20040211151544.GT4162@cygbert.vinschen.de> References: <20040211151544.GT4162@cygbert.vinschen.de> X-SW-Source: 2004-02/txt/msg00401.txt.bz2 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.