This patch implements __builtin_elementwise_abs as specified in
D111529.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/CodeGen/CGBuiltin.cpp | ||
---|---|---|
3109 | Did we discuss that this is different than __builtin_abs which is undefined for INT_MIN? |
clang/lib/CodeGen/CGBuiltin.cpp | ||
---|---|---|
3109 | I don't think we add nsw to vector signed integer subtract, so I guess using false here is consistent. |
Pass is_int_min_poison=true to llvm.abs.* to reflect latest update to the specification to make taking abs of the most negative integer undefined.
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.
Thanks! As making it UB does not really help with lowering I went back to allowing INT_MIN and updated the spec to explicitly spell out the behavior.
Two minor questions, but also LGTM as is.
clang/lib/Sema/SemaChecking.cpp | ||
---|---|---|
16538 | Given that I expect this particular test to occur fairly frequently, maybe worth abstracting into some sort of get-elementwise-type operation. | |
clang/test/Sema/builtins-elementwise-math.c | ||
25 | 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. |
Rebased after recent changes in D111985: changes the return type of SemaBuiltinElementwiseMathOneArg to bool and drop the CallResult argument. Also added tests with const, typedef'ed and variables with address space
clang/include/clang/Basic/DiagnosticSemaKinds.td | ||
---|---|---|
8748 | I feel like we must already have a diagnostic that covers this case... | |
clang/lib/Sema/SemaChecking.cpp | ||
16548 | Should this type undergo the usual promotions? | |
clang/test/Sema/builtins-elementwise-math.c | ||
25 | I was wondering about this myself, but also don't have strong opinions. |
Rebased and updated to use err_builtin_invalid_arg_type.
clang/include/clang/Basic/DiagnosticSemaKinds.td | ||
---|---|---|
8748 | Updated to use err_builtin_invalid_arg_type. | |
clang/lib/Sema/SemaChecking.cpp | ||
16548 | 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. |
clang/lib/Sema/SemaChecking.cpp | ||
---|---|---|
16548 | 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.) |
clang/lib/Sema/SemaChecking.cpp | ||
---|---|---|
16548 | 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. |
I feel like we must already have a diagnostic that covers this case...