Patch for stricter implicit conversions between vectors
Paolo Bonzini
bonzini@gnu.org
Thu Dec 14 17:31:00 GMT 2006
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
More information about the Gcc-patches
mailing list