This patch implements __builtin_elementwise_abs as specified in
What's the rationale for making abs undefined on the minimum value? AFAIK every actual simd implementation defines the result and they agree (and even if one didn't, it would be pretty easy to get the "right" result. Introducing UB here just seems like punishing users for no reason.
Two minor questions, but also LGTM as is.
Given that I expect this particular test to occur fairly frequently, maybe worth abstracting into some sort of get-elementwise-type operation.
For the purposes of C++ templates it might be nice to allow abs on unsigned (as the identity function). I don't have strong feelings though, and a library wrapping the builtins can do this themselves.
I feel like we must already have a diagnostic that covers this case...
Should this type undergo the usual promotions?
I was wondering about this myself, but also don't have strong opinions.
Rebased and updated to use err_builtin_invalid_arg_type.
Updated to use err_builtin_invalid_arg_type.
I'm not sure, but given that we only have a single argument then wouldn't it be sufficient to avoid promotion? I don't think promotion to wider types would impact the results of the provided builtins.
You set the type of the call to be the type of the argument, which means passing in a const int will result in a const int that's observable and probably unexpected. e.g. this will fail,
const int a = -12; static_assert(!std::is_const_v<decltype(__builtin_elementwise_abs(a))>);
(This can come up with overload resolution or in template specializations.)
Ah right. I originally was planning on just using getUnqualifiedType, but for consistency it seems better to just apply the usual unary conversions. I also added the test above and a codegen tests with short.