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: Patch for stricter implicit conversions between vectors

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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]