This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: front end changes for altivec
On Tue, 2001-11-27 at 19:01, Richard Henderson wrote:
> On Tue, Nov 27, 2001 at 06:52:55PM -0600, Aldy Hernandez wrote:
> > > How about __vector_size__(16) then?
> >
> > can anyone think of any way to get:
> >
> > vector int foo; /* v4si */
> > vector short bar; /* v2hi */
> > vector char hot; /* v16qi */
> > etc
> >
> > working for altivec in a target independent manner?
>
> 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).
actually, why can't we do this then:
#define __vector __attribute__ ((mode(V4SI)))
i still would like to have different modes for different vector types
(short, int, char).
>
> works. And char/short/int doesn't actually vary *that* widely.
> The targets for which these are not 1, 2 and 4 octets wide are
> fairly rare, so I'm willing to gloss over that. Especially
> since you can also work around this like so:
>
> #if SHRT_MAX == 32767
> typedef unsigned short u16;
> #elif INT_MAX == 32767
> typedef unsigned int u16;
> #else
> #error you're strange
> #endif
>
> __vector u16 foo;
>
> I think for stuff written for gcc itself we should encourage the use
> of mode(V4SI), or some other explicit element size + vector width
> syntax yet to be determined.
>
>
> r~
--
Aldy Hernandez E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.