This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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