Re: AltiVec [RFH] Overload resolution of vec_subs intrinsic fails

[Aldy Hernandez <aldyh at redhat dot com>]

> Unfortunately, the meaning that is desired in the altivec.h header is between
> the notion of "can convert without a cast" and the notion of "same type-ness".

No, we are mixing issues here.

Builtin_types_compatible_p in altivec.h is used as a poor man's
function overloading.  Castless conversions are used for the spe/e500
(think spe.h), and requires no magic on in header files, and has
nothing to do with builtin_types_compatible_p.

> What I do not understand is if the treatment of opaque types in my patch goes
> against comptypes' definition of compatibility as in "same type-ness".

Because opaque types have absolutely nothing to do with altivec.
Altivec doesn't have opaque types.

> Certainly the only user of opaque vector types, spe.h, never uses
> __builtin_types_compatible_p, and so does spe_expand_builtin -- opaque vector

Exactly.

> types are used in spe_init_builtins to init argument lists, but argument
> passing uses convert_for_assignment, and convert_for_assignment does succeed
> if one of the types is opaque and the other is not.  And there were no SPE

Exactly.  That is the desired behavior.

> I'd also like to know if the Altivec patch uses __builtin_types_compatible_p
> for a good reason, instead of using opaque types as well and doing all the
> instruction selection in the back-end.  Is the C++ implementation required to

Because we had no opaque types when the altivec code went in.
__builtin_types_compatible_p was written as a consensus on how to do
this overloading business.  Folks couldn't agree on anything better--
err, or rather, it was the ONLY thing everyone could agree on.

I also don't see how you can implement this overloading business with
just opaque types and back-end magic.  But I am willing to review such
patch.  I would much rather see a mess in the back-end (rs6000.c) in
one or two functions, rather than in the unmaintainable mess that
<altivec.h> is.

> use overloading?  Are there C++ tests for Altivec in the gcc testsuite?

No.  There are very few altivec tests to begin with.  The thorough
Motorola altivec testsuite has been contributed to the FSF, and Zack
volunteered to dejagnuify it.  We should try to run such tests for
both C and C++, at least on Darwin.

Cheers.
Aldy