Re: Vector Extensions in GCC

[Michael Eager <eager at mvista dot com>]

There is some nice synchronicity here.  I'd just stepped out of a 
longish conversation on exactly this subject with Daniel Jacobowitz
when he noticed your email.

Stan Shebs wrote:
> 
> 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.

Fine, should be easy to do.  Can also be extended to other architectures.

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

Generally good idea, except when you start talking about types.
Functions can be defined in an architecture independent fashion.
 
> 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).

I really dislike the idea of adding types to C/C++.  Speaking 
anecdotally, there were a continuous stream of issues concerning the 
bool type which were addressed by the C++ committee for several years 
after bool was added to the language.   I believe it is difficult 
to get a new type to work in a way that doesn't cause unexpected
behaviors.

On a more practical basis, making vector a reserved word causes
problems.  'vector' is used in existing programs and is a defined 
template class in STL.  Programs using this vector keyword could
not be compiled by any other standard-conforming C compiler.  As long 
as you don't mind breaking existing correct programs, being incompatible
with C++, and discarding literally decades of effort to make C/C++ 
a language in which you can write programs which are portable
from one machine to another, then I guess this isn't a problem. ;-)

As you mention, this is an allocation issue.  My view is that 
compilers should handle allocation of data to machine resources 
rather than having the user attempt to do this.  The only place where
C/C++ attempts to have the user handle allocation (i.e., the register
keyword) it turns out to range from superflous to pointless.

A vector is an array of values.  These can be allocated to a vector
register, either permanently or temporarily, if such exists on the 
target architecture, providing the use of the array is compatible with 
whatever allocation requirements you establish.  It would be very 
reasonable to allocate vectors in memory if the address of the vector 
or one of its elements was needed, with most operations occurring on a 
copy of the array in a vector register.  Seems like we do this all
the time with scalar values and general registers.

There are ABI issues.  They are not significantly different from the
issues of how to pass other aggregate values between functions.  Rules
can be established (as complicated as you might desire or despise) 
which permit short arrays to be passed in Altavec registers.  Since
C doesn't permit functions to return array values, it may not be 
possible to return a result in an Altivec register as distinguished
from modifying a function argument.  This seems a minor constraint.
Within a single compilation, and with static functions, there may be 
optimizations which the compiler can make which violate these ABI
rules in ways that cannot be observed by the user.

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

Don't do explicit vector operations in C.

Architectures change, and explicit operations tie your code to one
particular architecture and one particular version.  What may work
well for today's implementation may not work well on tomorrow's
processor with more and longer vector registers.

Programs written with explicit vector operations are not portable
to other targets or C compilers which do not have the same vector
operations.  It may be very useful to take working code which
runs on an Altivec processor and port it, unchanged, to another
processor.  There are any number of very valid reasons: different
cost, different power, different peripherals.  (I can guess that 
Motorola might have an interest in having Altivec-specific extensions 
which prevent or discourage people from porting code from Altivec
to other processors.  But you might consider me a pan-architecturist.  
I might be working with a Moto processor today and something entirely 
different tomorrow.)

It may be awkward for a GCC to determine that an array can be 
allocated to a vector register.  If this is the case, then perhaps 
the infrastructure of GCC should be improved to make it easier.  
I would expect that there are a set of relatively simple array
characteristics which can be identified which if 

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

Overloaded builtins seem like a good idea.

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

Someone mentioned the C9x structure constant.  I don't think that
is in C++, but it would be a likely future extension.

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

IMO, syntax extensions don't make sense for Altivec, so my view
is that they wouldn't make sense for other architectures.

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

If I were King of the World, I'd suggest that the devote their
efforts to extending GCC 3 internals to support allocating arrays 
to vector registers.

My appologies if this is rather more philosophical than a practical
comment about how to go about implementing this in GCC.  

--
Michael Eager     eager@mvista.com	408-328-8426	
MontaVista Software, Inc. 1237 E. Arques Ave., Sunnyvale, CA  94085