Vector Extensions in GCC

[Stan Shebs <shebs at apple dot com>]

I've been working on rewriting Motorola's AltiVec support for GCC,
and have some questions and comments about it.  First off, since
most people have heard different things, the support in question
is for a set of explicit vector processing extensions proposed by
Motorola ca 1997 or 1998, and since implemented in just about every
PowerPC compiler.  Conceptually the extensions consist of overloaded
builtin functions, plus a "vector" keyword to get source program
constructs allocated to vector registers.  (I know everybody wants
to dump on the concept right away, but bear with me for a moment.)
Full info is at www.altivec.org.

Tom Wood wrote the original patches for GCC around 2.91 days, and
then they got moved forward to 2.95.2.  Since then, Apple has made
further improvements in response to various bug reports, but mostly
within the context of Mac OS X, while other people have fixed problems
with GNU/Linux on PPC.  Unfortunately, the patches don't work well
in 3.x, and it looks to me like we need to start over (just as well,
since Motorola has never assigned their copyright).

Incidentally, for inspiration I've been looking at the MMX/SSE
support, but it's completely broken - the best I've been able to
do is to get some vector modes to appear in RTL, but then the
insns disappear and the actual assembly code has nothing.  Intel's
docs are pretty sketchy on all this, mostly focused on a mysterious
builtin __m128 type of indeterminate nature, and not present in GCC.
So as far as I can tell, I have no way to see how the existing
vector support *should* work.

As they're currently structured, the AltiVec bits come in several
feature groups, which I've listed in order of degree of effect
on the rest of the compiler.  These work in both C and C++.

0. Basic vector register support.  Names, classes etc.

1. Basic builtin functions, one per AltiVec instruction.

2. Overloaded builtins.  The builtin vec_add can become a vaddfp
(float) or vaddubm (unsigned byte modulo), etc, depending on the
type(s) of its arguments.  The compiler issues conversions as
needed.

3. Vector types.  You declare a variable to be "vector float",
"vector unsigned char", etc and it gets allocated to a vector
register.  Locals, globals, function parameters, and function
results can all be in vectors (yes, implies ABI consequence).

4. Vector constants.  There is a syntax extension where you can
say something like
    vector float var = (vector float) (1.0, 2.0, 3.0, 4.0);
and get "var" assigned to a vector register and filled in with
the given values.

5. Vector printing.  Not everybody does this, and it's a library
thing, but there is a %v directive to print vectors.

These are just the highlights; the working code in the patched
2.95.2 has many other little details accounted for. (vrsave
handling, etc)

Clearly groups 0 and 1 are conceptually OK for mainstream GCC,
while 3 and 4 are clearly dubious, although for our users' sake
(AltiVec extensions being popular), I will have to support them
in Apple's GCC, and presumably Linux folks will want to have them
also.  Group 2 I'm not sure about; the implementation is almost
entirely within rs6000 code, so impact is low, but it's stretching
the builtin concept a bit.

Now, the questions.  First, what is the right way to do explicit
vector operations in GCC?  Should it be done with additional user
visible types, or via attributes on existing types like float[4]?

Are overloaded builtins a good idea?  If so, do they need any
special support from generic code?

If vector constants are a bad idea, what should programmers do
instead?

Do the syntax extensions make sense for other architectures,
and if so, should they be made available in general?

What should PPC Linux (and *BSD, I guess) folks do about
adopting GCC 3, if vector extensions are no longer available?
Should they just stick with the patched 2.95.2?

Stan