From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aldy Hernandez To: "Joseph S. Myers" Cc: Aldy Hernandez , gcc@gcc.gnu.org Subject: Re: front end changes for altivec Date: Mon, 26 Nov 2001 16:39:00 -0000 Message-ID: <20011126163925.55335@taarna.cygnus.com> References: <1006772000.2390.4.camel@litecycle.cc.andrews.edu> X-SW-Source: 2001-11/msg01305.html Message-ID: <20011126163900.7J8XKBGJmVeoWLXYRd4TX5Jau5K9ltkVdHf1SELyY98@z> > > __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