This is the mail archive of the 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
> 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/
>>       (and something analogous for C++)
>>    2. At build time, this diff will be used to patch up
>>       gcc/ if needed.
> An interesting idea, but how is it different from Apple or whoever
> maintaining a locally-modified version?  If 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
> 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, but you WOULDN'T

> 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.                 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]