front end changes for altivec

[Joseph S. Myers]

On 26 Nov 2001, Aldy Hernandez wrote:

> the altivec specs require changes to the gcc front end.  this has been
> brought up before but no one has really commented.  now before everyone
> start raising shields and going "yuck, no way", hear me out.

You have of course read the previous thread on "Vector Extensions in GCC"  
from July.

>     __vector keyword:
>     
>     	__vector int	=> mode(V4SI)
>     	__vector char	=> mode(V16QI)
>     	etc etc

Precise rules?  Is __vector a type specifier that can be added to the
various lists of keyword type specifiers that can be used?  Which of the
type specifiers listed in C99 6.7.2#2 can it be used with?  I take it it
can't be used with typedefs, structs or unions.  Can it be used with
enums?  Why those particular sizes of vectors rather than others?  Will
__vector on its own imply __vector int?

Given proper answers, thorough documentation and testcases and a design of
an architecture-independent __vector keyword that allows for the variety
of vector types on different architectures, this is comparatively harmless
- as long as there are no implicit conversions between these types and any
other type in either direction and no operations can be applied to these
types other than passing to and returning from functions, and any explicit
conversions available are properly documented and justified.

>     vector constant initializers:
>     
>     	__vector int foo = (5, 8, 3, 2);
>     
>     (yes, those are parentheses, not curlys :-()

Obviously a bad idea - (5, 8, 3, 2) has a defined meaning that does not
depend on the context here.  This is worse than was suggested in July
(which was (vector float) (1.0, 2.0, 3.0, 4.0)) though that still ought to
be a compound literal instead.

-- 
Joseph S. Myers
jsm28@cam.ac.uk