Re: Vector Extensions in GCC

[Daniel Berlin <dan at cgsoftware dot com>]

Stan Shebs <shebs@apple.com> writes:

> 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 
Not really.
> - 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. 

This is because you aren't calling the builtins that make the right
splitters happen.
Or you aren't using the right flags, so it doesn't know it can use SSE
and MMX.

Try -msse -mmmx, and call the builtins (i'll send you the header if
somebodyh doesn't just submit it).

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

Actually, it's just defined as
 
typedef int __m128 __attribute__ ((mode (TI)));
typedef int __v4sf __attribute__ ((mode (V4SF)));
typedef int __v4si __attribute__ ((mode (V4SI)));

It's in a file that gcc doesn't have, nobody every bothered to submit
it (xmmintrin.h).

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

We have this.
We have vector types (V4SI, V4SF, etc) defined.

> 
> 1. Basic builtin functions, one per AltiVec instruction.
Got this for x86 too.

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

However, we already have the majority of the infrastructure for this.  (I can't remember whether i ever checked in the C++ patch
necessary to do the implicit conversions. You'll just get errors about
type conversions otherwise).

You may have to add in some of the other Type nodes (it's rather
simple work), like V8SF or whatever.

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

We already have it done with attributes.
See the definition of __m128 i pasted above.

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

I'm a ppc linux folk, and i've never used the vector extensions.

> Should they just stick with the patched 2.95.2?
> 
> Stan

-- 
"The other day, I was walking my dog around my building...  on
the ledge.  Some people are afraid of heights.  Not me, I'm
afraid of widths.
"-Steven Wright