From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23906 invoked by alias); 16 Feb 2004 16:00:13 -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 23868 invoked from network); 16 Feb 2004 16:00:12 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 16 Feb 2004 16:00:12 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i1GG0Ab20105 for ; Mon, 16 Feb 2004 11:00:10 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i1GG09M27363 for ; Mon, 16 Feb 2004 11:00:09 -0500 Received: from cygbert.vinschen.de (vpn50-42.rdu.redhat.com [172.16.50.42]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i1GG08X17940 for ; Mon, 16 Feb 2004 08:00:08 -0800 Received: by cygbert.vinschen.de (Postfix, from userid 500) id 5C078580C6; Mon, 16 Feb 2004 17:00:02 +0100 (CET) Date: Mon, 16 Feb 2004 16:00:00 -0000 From: Corinna Vinschen To: gdb-patches@sources.redhat.com Subject: Re: [RFA] sh-tdep.c: optimize fv_reg_base_num and dr_reg_base_num Message-ID: <20040216160002.GJ18953@cygbert.vinschen.de> Reply-To: gdb-patches@sources.redhat.com Mail-Followup-To: gdb-patches@sources.redhat.com References: <20040211151544.GT4162@cygbert.vinschen.de> <16432.57749.894105.453337@localhost.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16432.57749.894105.453337@localhost.redhat.com> User-Agent: Mutt/1.4.2i X-SW-Source: 2004-02/txt/msg00407.txt.bz2 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 :-( Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc.