This is the mail archive of the 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

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:
Professional Gypsy
Red Hat, Inc.

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