From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18657 invoked by alias); 27 Nov 2001 23:06:18 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 18585 invoked from network); 27 Nov 2001 23:06:13 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 23:06:13 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id fARN6Cu15000 for ; Tue, 27 Nov 2001 15:06:12 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 27 Nov 2001 15:05:55 -0800 Received: from apple.com (vpn-gh-30.apple.com [17.254.136.29]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id fARN69G07292; Tue, 27 Nov 2001 15:06:09 -0800 (PST) Message-ID: <3C041C4B.1D61A4E9@apple.com> Date: Mon, 19 Nov 2001 12:54:00 -0000 From: Stan Shebs X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Aldy Hernandez CC: Ziemowit Laski , Ira Ruben , gcc@gcc.gnu.org Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec) References: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-SW-Source: 2001-11/txt/msg00909.txt.bz2 Aldy Hernandez wrote: > > Be that as it may, even if we implement __vector correctly, we still > need patches for vector constant initializers, because there is just > no way in hell the following is going to be accepted: > > vector int foo = ((vector int)(1,2,3,4)); > > I assume we will add extensions with { }'s that will be incorporated > into gcc, but then have additional patches for ()'s that will never be > incorporated. You could always adopt the strategy of supporting it with the additional patches, but deprecated, for a year, then drop it from the next version. If users get tangible benefits from switching, they'll be ready to change. (For instance, the possibility of sharing at least some source with an SSE version...) > It would be really nice if you guys contributed your internal changes > on a more regular basis. Stan tells me there lots of Darwin > optimizations in the backend that you guys haven't contributed. It's > just easier to get a better overall picture if we're all looking at > the same code base. There aren't many backend changes not tied to other code that can't be contributed, such as Motorola's AltiVec support. But you're right, we've been falling behind in contributing local changes. Spending too much time arguing about controversial changes I guess... :-) Stan From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: Aldy Hernandez Cc: Ziemowit Laski , Ira Ruben , gcc@gcc.gnu.org Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec) Date: Tue, 27 Nov 2001 15:06:00 -0000 Message-ID: <3C041C4B.1D61A4E9@apple.com> References: X-SW-Source: 2001-11/msg01410.html Message-ID: <20011127150600.CCJzV2TSNOWKuBsb5ot46lBmWoQIWb8MFojGmnI-e0k@z> Aldy Hernandez wrote: > > Be that as it may, even if we implement __vector correctly, we still > need patches for vector constant initializers, because there is just > no way in hell the following is going to be accepted: > > vector int foo = ((vector int)(1,2,3,4)); > > I assume we will add extensions with { }'s that will be incorporated > into gcc, but then have additional patches for ()'s that will never be > incorporated. You could always adopt the strategy of supporting it with the additional patches, but deprecated, for a year, then drop it from the next version. If users get tangible benefits from switching, they'll be ready to change. (For instance, the possibility of sharing at least some source with an SSE version...) > It would be really nice if you guys contributed your internal changes > on a more regular basis. Stan tells me there lots of Darwin > optimizations in the backend that you guys haven't contributed. It's > just easier to get a better overall picture if we're all looking at > the same code base. There aren't many backend changes not tied to other code that can't be contributed, such as Motorola's AltiVec support. But you're right, we've been falling behind in contributing local changes. Spending too much time arguing about controversial changes I guess... :-) Stan