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

[Stan Shebs <shebs@apple.com>]

Ziemowit Laski wrote:
> 
> But this brings up a more general question, one that I've been meaning to
> ask of the wider community for quite some time: Should we come up with a
> generalized architecture in GCC (for all front-ends) to enable front-end
> extensions:
>    1) only for specific platforms (e.g., Altivec for PPC targets,
> 'dllexport'
>       for Windows, etc.); and/or
>    2) only when explicitly specified via the configure script (e.g.,
>       '--enable-altivec-keywords', '--enable-pascal-strings')

When you put it that way, my general reaction is to say "bleah". :-)

GCC philosophy has never been to implement every feature ever seen
in somebody else's compiler, but instead to have a single compiler
that behaves consistently across a range of architectures and
operating systems.  There are frontend extension mechanisms, such
as pragmas and attributes for C dialects for instance, as well as
builtin functions, so there is plenty to work with already.  It
may be that these are inadequate, but the case would have to
be pretty compelling on technical grounds.

For instance, in the case of AltiVec extensions, the effect of
vector/pixel keywords can be almost entirely achieved with mode
attributes, the overloaded builtins could be handled by adding
a general concept of overloaded builtins, leaving only the vector
constant syntax as an oddball.  From what I know of the AltiVec-
using population, the total aggregate effort of changing the
syntax of all the vector constants in source code might add up
to as much as one day - less than the effort needed to get the
extension working in GCC.  So should we implement the extension
and support it forever, or get users to spend a few minutes to
change their sources?

The moral of the story with respect to AltiVec is that GNU people
should try to be more involved when new technologies are being
introduced.  As far as I know (I admit to being out of the loop
myself), the AltiVec programming model was designed by a group
working on various proprietary compilers, and the question of GCC
support didn't come up until later.  There were some real boners,
such as the context sensitivity of the vector keyword, that I think
could have been avoided if some GCC folks had participated.

It's easy to say "oh, I can't do anything without having a signed
contract first" or "why should I care about PowerPC/x86/ARM/etc",
but in cases like these some upfront interest and nosiness will
pay off in the long run; we can then spend our development time on
improvements that benefit everybody, rather than tricky hacks to
support another limited-interest target-specific extension.

Stan