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: A Far Less Ambitous AltiVec patch

On 3 Feb, 2004, at 11.56, Mark Mitchell wrote:

But this is insufficient for AltiVec, where more than one AltiVec type can map to the
same generic vector layout. For example, the types 'vector unsigned short', 'vector bool short'
and 'vector pixel' all are implemented as a vector holding 8 unsigned short values.

That's a bug, then, and should be fixed.

It's fine for these vectors to have the same machine mode, just as int and long often have the same machine mode. But, just as int and long have separate types, so should these vectors.

A VECTOR_TYPE has a slot for saying what the element types are. They should be different in each of the cases you give above.

So you're saying I should create stand-alone "mixin" types like 'pixel' and 'unsigned bool'? It seems a bit weird, since these types are not really meaningful outside of a VECTOR_TYPE, but I guess that's not a big issue...

And, the generic mangling code for VECTOR_TYPEs should just encode the number of elements and the type of the elements.

So, I'm still left with the problem of mangling 'pixel' and 'unsigned bool' -- how should I do it without creating a target hook? :-) Unless you mean that 'pixel',
'unsigned bool' and such should be pre-defined in the generic part of the compiler? Please advise,

Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

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