This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: Target-specific Front-Ends? (Was: front end changes for altivec)

From: Richard Henderson <rth at redhat dot com>
To: Ziemowit Laski <zlaski at apple dot com>
Cc: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>, gcc at gcc dot gnu dot org
Date: Tue, 27 Nov 2001 13:43:35 -0800
Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec)
References: <Pine.LNX.4.33.0111272030001.29605-100000@kern.srcf.societies.cam.ac.uk> <6E5F268F-E37C-11D5-AE62-0030658361CA@apple.com>

On Tue, Nov 27, 2001 at 01:19:24PM -0800, Ziemowit Laski wrote:
> > provide well-defined ways of using target-specific features without
> > causing problems for the rest of the compiler.
> 
> The main thrust of my proposal has been to create a mechanism intended
> PRECISELY to prevent problems for the rest of the compiler.

Nevertheless, there are many other targets for gcc that do support some
form of SIMD, and thus we ought to come up with a solution that works
across all of them.

> But is there any harm in INCLUDING them in the tree?

I do not want to hack up our build mechanism.  It's already horrible.

Given that there appear to be several folks interested in this, it
might be acceptable to have an altivec branch in the regular gcc
repository, but that's as far as I'd be willing to let it go.

r~

References:
- Re: Target-specific Front-Ends? (Was: front end changes for altivec)
  - From: Joseph S. Myers
- Re: Target-specific Front-Ends? (Was: front end changes for altivec)
  - From: Ziemowit Laski

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]