Baby's First AldyVec/AltiVec patch

[Ziemowit Laski]

Here's my first take at integrating AldyVec with AltiVec in the
FSF TOT compiler.  With it, you can build the compiler and hand-run
the AldyVec/AltiVec test cases (both old and new).  I have not tried
bootstrapping or running the complete test suite yet, will do that next.

The purpose of posting this preliminary patch is twofold:
   (1) So that people could point out obvious, glaring errors in
       my approach -- provided they suggest alternative approaches,
       of course. :-)
   (2) So that we can start thinking of where this stuff should be
       committed, both in the short- and long-term.  For the immediate
       future, I'd be tempted to create an altivec-branch or some such,
       so that other PowerPC target maintainers can take these bits for
       a spin.  It's probably premature at this stage to decide which
       GCC release (3.4? 3.5?) this would wind up in.

Here's an executive summary of what this patch accomplishes:
   (1) Adds a '-faltivec' switch (for Darwin targets only), which is
       similar to '-maltivec' except that the <altivec.h> header gets
       pulled in automatically as well.
   (2) Adds support for context-sensitive keywords.  This is accomplished
       via what I call "conditional macros", whereby a predicate is 
evaluated
       to decide whether a macro (in our case, "vector", "pixel", etc.) 
should
       be expanded or not.  This is controlled by a target hook, and is
       turned off completely unless you specify '-maltivec' or 
'-faltivec'.
   (3) Adds support for 'vector pixel' and 'vector bool ...' types as
       _distinct_ from 'vector unsigned ...' (This was missing from 
AldyVec),
       and adds canonical name-mangling for the AltiVec types.
   (4) Adds support for treating comma expressions, when cast to a 
vector type,
       as vector initializers (e.g., "(vector signed int)(1, 2, 3, 4)"), 
as
       the Apple/Motorola AltiVec syntax requires.  The AldyVec 
array-style
       initializers ("{1, 2, 3, 4}") are supported as well.
   (5) Adds support for the -W[no-]altivec-long-deprecated flag (for 
Darwin
       targets only) to optionally suppress warnings about uses of 
'vector long ...'
       types.

The patch is incomplete in (at least) that there is no demangler for the
AltiVec types, and that <altivec.h> does not contain all the allowed 
permutations
of operation/predicate signatures (and those it does contain may not be
appropriately cv-qualified).

I don't think that the PowerPC-specific portion of this patch should 
arouse much
controversy.  However, the patch also touches common areas in the C and 
C++
front-ends, although I used target hooks (all disabled unless 
'-maltivec' or
'-faltivec') whenever possible.

Probably the most troublesome (potentially) spot is the 
context-sensitive keyword
expansion, which required the creation of a circular lookahead buffer 
in the lexer,
and the conditional expansion of macro bodies.  I welcome any and all 
ideas on how
to make this more robust/streamlined.  It appears that the C++ parser 
also relies on some
sort of lookahead buffer, and it would be good if we could integrate 
the two
mechanisms.

Anyhoo, I guess that's enough verbiage for now.  Please look over this 
diff and let
me know what you think.  If you have question, bring 'em on. :-)  I 
marked my mods
'APPLE LOCAL' for now, to be able to tell them apart from ongoing TOT 
changes.

Enjoy, and have a good weekend,

--Zem

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: aldyvec-altivec-20031219.txt
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20031219/68b54c55/attachment.txt>
-------------- next part --------------

--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477