simon_tatham added a comment. In D67160#1704840 <https://reviews.llvm.org/D67160#1704840>, @rsmith wrote:
> If overload resolution can't distinguish between overloads that perform a lax > vector conversions and those that do not, we should fix that in overload > resolution rather than papering over it with a change of per-target default I'm a bit late coming back to this, but //now// I've remembered why I wanted this change, and why clang's normal overload resolution doesn't do quite what the MVE polymorphic intrinsics want. I'm in the middle of writing implementations of the `vsetq_lane` family of intrinsics. These take a vector as input, a scalar of the same type as the vector lane, and a lane index, and returns a modified vector with the specified lane replaced by the scalar input value. In other words, the overloaded versions consist of things like int8x16_t vsetq_lane(int8_t, int8x16_t, int); int16x8_t vsetq_lane(int16_t, int16x8_t, int); int32x4_t vsetq_lane(int32_t, int32x4_t, int); ... and so on for unsigned and floating types too. Now if the user calls myvector = vsetq_lane(23, myvector, 1); then I think they reasonably expect the choice of polymorphic intrinsic to be based on the type of the //vector// parameter, because the integer literal 23 in the scalar parameter could have been intended to be any of those integer types. But the strict rules of C say that it has type `int` (which in this case matches `int32_t`). So if you do this with `myvector` being (say) an `int8x16_t`, you get an error message complaining that the call is ambiguous: the vector parameter matches one of those prototypes, but the scalar parameter matches another, and neither one matches both. Ideally I'd like to be able to configure this particular family of overloaded functions to give strictly higher priority to the vector type than the scalar type, in resolving this ambiguity. Turning off lax vector conversions has that effect, but I do agree with you that it would be better not to do it that way. So, do you have any thoughts on a better approach? The only one I've so far thought of is to add extra spurious overloaded declarations in the header file for integer types that things might have accidentally been promoted to. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D67160/new/ https://reviews.llvm.org/D67160 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
