This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Target-specific Front-Ends? (Was: front end changes for
- From: Devang Patel <dpatel at apple dot com>
- To: Aldy Hernandez <aldyh at redhat dot com>
- Cc: Devang Patel <dpatel at apple dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 28 Nov 2001 11:12:47 -0800
- Subject: Re: Target-specific Front-Ends? (Was: front end changes for
On Tuesday, November 27, 2001, at 06:23 PM, Aldy Hernandez wrote:
>>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
>
>>> Consider a preprocessor that takes current Altivec C code and produces
>>> either standard or extended C code (GNU extensions). If adopting the
>>> existing Altivec syntax is too painful, a second choice might be to
>>> figure
>>> out syntax choices that would make such a preprocessor very easy to
>>> write.
>>> Then we don't have to ask existing users to rewrite their code.
>
>> Yup, I thought about this too. It's plausible, but a pretty
>> substantial
>> effort, and not easy to do robustly with the tools we've got.
>
> I've actually thought about implementing generic front end extension
> support to gcc for this kind of nonsense. Sort of like a preprocessor
> ...
> what do y'all think?
- One very big disadvantage of GCC, compared to other compilers, is
compile time speed. I think it may not be a good idea to eat millions
of
tokens just to take care of couple of tokens. Every machine cycle
counts.
- It may open pandora's box for many unnecessary extensions and put
GCC users in difficult situation when these extensions are not carry
forwarded.
Instead of extra preprocessor , It's would be nice to have good plug-in
architecture
in GCC front end (like GCC back end architecture)
- Plus, this kind of extension means Altivec will always remains outside
of main
GCC front end engine. And it may not be a good idea in long run,
because
-- Any major redesign/improvement of front end will not consider
Altivec during
design and will require extra support to keep Altivec extension up
to date.
-- Any future C-based language standard update may introduce new things
which may collide with spec supported by such Altivec extension.
This
can create lots of problems for Altivec users as well as GCC
developers.
It is better to accept clear set of Altivec specs as part of GCC
front end so that
GCC can raise hands against such future collisions. (Which means,
this
may be the time two clean up any ambiguity in Altivec spec, if
there is any, as
far as GCC is concerned)
my thoughts,
Devang