This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Baby's First AldyVec/AltiVec patch

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

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

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,


Attachment: aldyvec-altivec-20031219.txt
Description: Text document

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]