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)


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.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085


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