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 13.25, Mark Mitchell wrote:

Aldy Hernandez wrote:
[Respective maintainers should comment on the non AltiVec parts.
Mark/Jason could you at least take a look at the vector mangling code
Ziemowit wrote?]
> Most of the remaining bits are also Darwin or RS6000-specific. The only
> platform-independent change is the addition of a target hook for
> mangling of vendor-specific types (which AltiVec types are). Luckily,
> no demangler changes are needed.
I am not a big fan of vendor specific manglers, especially if it's
just for vectors. We should come up with a generic way of mangling
vector types in GCC.


Since we have a uniform way of representing them internally we should be able to have a uniform way of mangling them.

Mark, see my response to Aldy. The generic vector infastructure in inadequate in supporting the AltiVec type system ('vector unsigned ...' vs. 'vector bool ...',
'vector unsigned short' vs. 'vector pixel'), so any generic mangling scheme will likewise be inadequate. Unless, of course, you give me permission to unconditionally introduce the AltiVec type system into the compiler... do you? :-)

The ABI actually already has a way of dealing with vendor-extended types; see the spec. It involves spelling out the name of the type, which seems perfectly reasonably to me.

But that's what my patch does (via the 'u' and 'U' encodings). How else would you like to see this done?

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]