From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aldy Hernandez To: Richard Henderson Cc: "Joseph S. Myers" , gcc@gcc.gnu.org Subject: Re: front end changes for altivec-- conclusion Date: Tue, 27 Nov 2001 18:00:00 -0000 Message-ID: <1006912994.5176.67.camel@litecycle.cc.andrews.edu> References: <1006874643.5176.8.camel@litecycle.cc.andrews.edu> <20011127132756.A30114@redhat.com> <1006898082.5178.41.camel@litecycle.cc.andrews.edu> <20011127140031.E30114@redhat.com> <1006908775.5178.45.camel@litecycle.cc.andrews.edu> <20011127170133.A30341@redhat.com> <1006910794.5178.61.camel@litecycle.cc.andrews.edu> <20011127175001.B30389@redhat.com> X-SW-Source: 2001-11/msg01447.html Message-ID: <20011127180000.8RV7JEuSqDa3G75rU_ZbuVn9I53GO22fg2BVbF4zGiA@z> On Tue, 2001-11-27 at 19:50, Richard Henderson wrote: > On Tue, Nov 27, 2001 at 07:26:34PM -0600, Aldy Hernandez wrote: > > > Modulo the varying size of "short", > > > > > > #define __vector __attribute__((__vector_size__(16))) > > > > the thing is that there are builtins that expect V4SI, or V4SF, or > > V16QI, etc. i guess i can have all vectors be V4SI (or vector_size(16)) > > and cast them (which does nothing, but quiets the parser). > > Examine the type that __vector is modifying ("short" for this example) > and you get HImode. Divide vector_size(16) by sizeof(HImode) to yield 8. > Put it all together and to get V8HImode. Voila. thanks. ok guys, i think i have all the pieces of the puzzle thanks to a nice conversation with richard.(modulo that ()'s crap for initializers-- that'll have to be non FSFable patches). i think it looks like: #define __vector __attribute__((__vector_size__(16))) then find out the mode from the type being modified... V16QI in the following example: __vector signed char foo; from then everything falls nicely into place. in a couple weeks i'll start implementing the infrastructure along with an altivec implementation. i'm taking volunteers for the x86 version :). enough talking, back to hacking. aldy