This is the mail archive of the
mailing list for the GCC project.
Re: Target-specific Front-Ends? (Was: front end changes for altivec)
- From: Ziemowit Laski <zlaski at apple dot com>
- To: Stan Shebs <shebs at apple dot com>
- Cc: Ira Ruben <ira at apple dot com>, gcc at gcc dot gnu dot org
- Date: Tue, 27 Nov 2001 14:50:25 -0800
- Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec)
On Tuesday, November 27, 2001, at 02:20 , Stan Shebs wrote:
> Ziemowit Laski wrote:
>> My point (or, perhaps, points) were:
>> 1. GCC is used on a variety of real-world platforms
>> 2. In that same real world, people have invented tons of
>> target-specific extensions to C and C++ to get extra mileage
>> out of their particular hardware/OS setup.
>> 3. Ergo, we should be able to come up with a 'configure'-based
>> mechanism for enabling selected extensions for selected target
>> WHILE LEAVING THEM HIDDEN FROM MAINLINE USERS.
> You're right; we certainly can. But should we? GCC has built up
> a huge user base without support for arbitrary frontend extensions.
> If the extensions were so important, we would see messages about them
> every week on this list, but historically there have been very few
> requests. In fact, AltiVec is by far the largest and most complex
> target-specific extension I know of, and even then the world total
> amount of AltiVec-extension-using code is maybe several thousand
> lines of C. If there are more important or widespread extensions
> that GCC ought to support, now would be a good time to list them.
Very true -- speak up, people! :) :)
>> How could we go about step 3? I'm sure there are a million ways,
>> but let me illustrate one possible scenario (for AltiVec):
>> 1. We create a file called gcc/config/rs6000/c-parse.in.diff
>> (and something analogous for C++)
>> 2. At build time, this diff will be used to patch up
>> gcc/c-parse.in if needed.
> An interesting idea, but how is it different from Apple or whoever
> maintaining a locally-modified version? If c-parse.in changes,
> then the diff will likely be broken, and since you're saying it's
> not the responsibility of the C frontend maintainer to keep the
> c-parse.in.diff working, the AltiVec maintainer has to step in
> and rework the diff to make it useful again - which is exactly
> what one of us does when we import FSF sources.
Yes, you'll need to fix up c-parse.in.diff, but you WOULDN'T
HAVE TO DO THE IMPORT IN THE FIRST PLACE! :) :) :)
> Part of my concern with a mechanism to support arbitrary change
> is that the consequences are unpredictably broad. AltiVec-style
> vector constants, for instance, entail not only the syntactic
> extension, but also a new tree node type, and additional code
> throughout the compiler.
Of course -- and GCC already provides a place for the back-end
portion of this code -- the config/ folders. All I'm trying to
do is find a warm, friendly place for the front-end portion. :)
Ziemowit Laski Apple Computer, Inc.
firstname.lastname@example.org 2 Infinite Loop, MS 302-4SN
+1.408.974.6229 Fax .1344 Cupertino, CA 95014-2085