Re: front end changes for altivec

[Aldy Hernandez <aldyh@cygnus.com>]

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

i believe it can only be used with signed, unsigned, int, short, float,
and char.  you can't use it with typedefs or enums.

> can't be used with typedefs, structs or unions.  Can it be used with

but they can be used as fields in a struct.

> enums?  Why those particular sizes of vectors rather than others?  Will
> __vector on its own imply __vector int?

__vector must be first among type specifiers.  the specs are rather skekchy,
but it seems like you need to specifically mention int.  you can also
have pointers to these types (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

ok, but how would we differentiate between the diff vector sizes.
altivec has "vector int" being V4SI, but vector int could mean V2SI in
mmx.  suggestion welcome while i think through this.

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

correct.  you can't convert between any of the vector types.  the following
just does a straight copy, no conversion (nop):

  vector short b;
  vector int a = (vector int) b;

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

oh sorry, it has to be casted and it has to have an extra set of ()'s so
it might not be too bad:

	vector int foo = ((vector int)(1,2,3,4));

this kinda sucks all together because i don't think gcc has vector constants
at all, do we?  we could pass it as a BLKmode or as a struct right?

this might not be too bad if we come up with a mechanism for all simd 
processors.  i'm still wondering how to manage the diff sizes.

does this make it clearer?

aldy