Re: Patch for stricter implicit conversions between vectors

[Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>]

Andrew Pinski wrote:
> A couple of comments about this patch.
> First I think it will break the following for VMX:
> #include <altivec.h>
> vector unsigned short f(vector unsigned char a, vector unsigned char b)
> {
>  return vec_vmuloub(a, b);
> }
>
> Which is valid.

Do you *think* or does it break?  Did you run the vmx testsuite, which 
is about as comprehensive as it can be with respect to the types of 
operand and returned types?

Builtin vmuloub has always returned "wrong" types, because it derives 
its types simply from the modes of the altivec_vmuloub pattern.  For 
this reason, the C front-end expands vec_vmuloub to the 
__builtin_vec_vmuloub builtin instead: this one is expanded by 
resolve_overloaded_builtin to add the appropriate casts on both the 
arguments and the results.

r_o_b runs before types are checked, so Mark's patch would check types 
*after* r_o_b has added the appropriate fold_converts.

> Second:
> > Index: gcc/config/rs6000/altivec.h
>
> I rather have you patch builtins to have the correct type, this will
> help memory usage with code with a lot of intrinsics and also fix
> vec_vmuloub testcase (as I think it is the same issue).

I didn't understand actually if you checked or not.  I do agree however 
that these changes would seem unnecessary given the rs6000-c.c changes.

As for the rest of the e-mail, it's spread with too many "I think" that 
are but confusing me, Mark, and whoever else is trying to communicate. 
Please back up your assertions.

Paolo