This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: front end changes for altivec-- conclusion


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]