Re: A Far Less Ambitous AltiVec patch

[Ziemowit Laski <zlaski at apple dot com>]

On 2 Feb, 2004, at 19.03, Richard Henderson wrote:

> On Mon, Feb 02, 2004 at 05:28:09PM -0800, Ziemowit Laski wrote:
> > > We just ceded you generic type-specific mangling.  So why
> > > would you need to do *anything* special for rs6000?
> >
> > You mean I can introduce the AltiVec type system into the generic part
> > of the compiler?
>
> NO.  What I said is "generic type-specific (vector) mangling".  What
> is confusing about that?  What about that implies AltiVec?
>
> My question remains -- what *beyond* generic type-specific vector
> mangling is needed for AltiVec support?

I thought I already explained this, but let's try again: :-)

The generic GCC vector infrastructure distinguishes vector types by 
exactly two things:
The type of scalar elements inside the vector (int, unsigned short, 
etc.) the the
number of such elements.  So, if you have two vector types designed to 
hold, e.g.,
4 floating-point values, the two will be in fact one and the same type.

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.  Thing is,
they must nevertheless be kept distinct.  This is analogous to 'int' 
and 'long' on ILP32 systems
-- even though they share the same physical representation, they are 
logically distinct (and
are mangled differently, too).

In C++, it is perfectly legal for someone to overload a function as 
follows:

  void foo(vector unsigned short vec) { ... }
  void foo(vector bool short vec) { ... }
  void foo(vector pixel vec) { ... }

Under the generic vector regime currently supported by FSF gcc, all 3 
functions will appear
to have exactly the same signature, since the 'vec' argument for each 
gets lowered to
an unsigned_V8HI_type_node.  For AltiVec to work, these 3 functions 
must not only be allowed
to co-exist -- and hence require different manglings, which is where 
the target hook comes in. :-)

Hope this helps -- if you still have questions, please let me know.

Thanks,

--Zem
--------------------------------------------------------------
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