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

[Aldy Hernandez]

>>>>> "Ziemowit" == Ziemowit Laski <zlaski@apple.com> writes:

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

This is a neat hack, but someone will still have to maintain a
separate set of patches for altivec stuff, which is what i'm trying to
avoid.

If we do the __vector stuff and come up with a generic way applicable
to all SIMD architectures, then we a) improve gcc b) do not cause a
maintenance nightmare.

It might be eaiser for Apple to keep separate trees because you only
support one target, and don't contribute your code as often as we do.

Be that as it may, even if we implement __vector correctly, we still
need patches for vector constant initializers, because there is just
no way in hell the following is going to be accepted:

        vector int foo = ((vector int)(1,2,3,4));

I assume we will add extensions with { }'s that will be incorporated
into gcc, but then have additional patches for ()'s that will never be
incorporated.

 >    2. It will be the sole responsibility of the users of AltiVec
 >       extensions to maintain the diff so that it can be applied
 >       cleanly; mainline developers need not and SHOULD NOT be
 >       forced to deal with this.

Let's try to try to come up with a generic solution, and then use your
approach for whatever we know will NEVER make it into mainline gcc.

 >> the world?  Ironically, this extension makes our internal version of
 >> GCC more complicated and time-consuming to merge with FSF sources, so
 >> our imports take longer and have more problems, which means that your
 >> own daily work today has been made more difficult by the expedient
 >> choice of several years ago.

 > True, but I suspect that we (i.e., Apple) are far from the only ones
 > in this situation, which is why it is so desirable, IMHO, to be
 > able to put all such target-specific stuff in the FSF tree to begin
 > with!  Of course, we already do this for back-end/codegen stuff -- we
 > just need to generalize this model.

It would be really nice if you guys contributed your internal changes
on a more regular basis.  Stan tells me there lots of Darwin
optimizations in the backend that you guys haven't contributed.  It's
just easier to get a better overall picture if we're all looking at
the same code base.

Aldy