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

[Stan Shebs <shebs@apple.com>]

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.

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

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.

Stan