From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: Ziemowit Laski Cc: Ira Ruben , gcc@gcc.gnu.org Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec) Date: Tue, 27 Nov 2001 14:20:00 -0000 Message-ID: <3C041193.DBC0A69@apple.com> References: X-SW-Source: 2001-11/msg01395.html Message-ID: <20011127142000.Lnn1pZHBdZ7uiQe1tWiZxXgiCADV7vOHuQ-dHxBbsDs@z> 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