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


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]