From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20617 invoked by alias); 14 Oct 2009 16:18:21 -0000 Received: (qmail 20608 invoked by uid 22791); 14 Oct 2009 16:18:20 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-vw0-f183.google.com (HELO mail-vw0-f183.google.com) (209.85.212.183) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Oct 2009 16:18:15 +0000 Received: by vws13 with SMTP id 13so2629298vws.14 for ; Wed, 14 Oct 2009 09:18:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.108.39 with SMTP id d39mr12962483vcp.12.1255537092969; Wed, 14 Oct 2009 09:18:12 -0700 (PDT) In-Reply-To: <20091014151518.GA8113@hungry-tiger.westford.ibm.com> References: <20091001185752.GA28820@hungry-tiger.westford.ibm.com> <303e1d290910130630v33b0fe11sd59a5a806b4eb948@mail.gmail.com> <20091013202500.GA9438@hungry-tiger.westford.ibm.com> <303e1d290910131702r13407263i1b226dcad22dddc7@mail.gmail.com> <20091014151518.GA8113@hungry-tiger.westford.ibm.com> Date: Wed, 14 Oct 2009 16:19:00 -0000 Message-ID: <84fc9c000910140918g36668de8sf50d0c5cd43f5249@mail.gmail.com> Subject: Re: [PATCH] Fix builtin attributes on powerpc From: Richard Guenther To: Michael Meissner , David Edelsohn , gcc-patches@gcc.gnu.org, Jakub Jelinek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2009-10/txt/msg00918.txt.bz2 On Wed, Oct 14, 2009 at 5:15 PM, Michael Meissner wrote: > On Tue, Oct 13, 2009 at 08:02:04PM -0400, David Edelsohn wrote: >> On Tue, Oct 13, 2009 at 4:25 PM, Michael Meissner >> wrote: >> >> > It is too late for GCC 4.5 to do things in a common fashion. =A0The re= al solution >> > is to move the backend builtins into the main builtins. =A0I had some = patches to >> > allow backends to optionally do this, and when 4.6 opens up we can exp= lore >> > this. >> >> The question is whether Jakub and other GCC port maintainers agree >> that this is the direction to go in the future, not that it is >> implemented in all targets for GCC 4.5. =A0I want to see some consensus >> before this patch is committed. >> >> > I agree MAX_RS6000_BUILTINS is more consistant, but RS6000_BUILTIN_COU= NT is >> > what was originally used, so I didn't change that. >> >> Please make the change as part of the patch. > > Unfortunately, I'm not sure I can do all of this in the time remaining. = =A0I > suspect it will take at least 5 days of time to build the infrastructure = to do > what rth and richi have asked for. =A0The goals as I see it are: > > =A01) Move the creation of the MD builtins to be part of the normal built= in > =A0 =A0 creation, in a seamless fashion without forcing the backends to h= ave a > =A0 =A0 flag day changing their builtin handling (originally from rth). = =A0Part of > =A0 =A0 this was done in this RFC patch that provided the new infrastruct= ure: > =A0 =A0 http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01820.html > > =A02) Allow for lazy creation of the trees for builtin functions and types > =A0 =A0 (originally from richi). =A0I know where the places that need to = be modified > =A0 =A0 are, but it will involve changes in both the front ends and middl= e end to > =A0 =A0 do this. =A0This will take some amount of time to get right. > > =A03) Move all of the rs6000 builtins (the various bdesc tables in rs6000= .c) to > =A0 =A0 this new scheme. =A0Just due to the number of builtins that exist= in the > =A0 =A0 rs6000 backend, this will take some time to make sure all of the = types, > =A0 =A0 etc. are properly created. > > =A04) Then possibly get x86, arm, etc. to move to the new scheme. > > However, I can't do #3 until at least the infrastructure changes are in p= lace, > and given we are in stage 3 right now, I don't think this is the time for= doing > it. =A0Thus the 2 different patches that I have submitted are a stopgap m= easure Well, I agree. This is not something for stage3. Richard.