Unexpected codegen for __builtin_elementwise_bitreverse on unsigned char and short #84047
Comments
|
Seems like its zext the input and calling the i32 bitreverse. I thought the __builtin_elementwise* were for vectors, not scalars? |
Documentation says:
|
|
@llvm/issue-subscribers-clang-codegen Author: Shafik Yaghmour (shafik)
Given the following: https://godbolt.org/z/M1hEqs9q5
unsigned char f(unsigned char a) {
return __builtin_elementwise_bitreverse(a);
}
unsigned short f(unsigned short a) {
return __builtin_elementwise_bitreverse(a);
}
signed char f3(signed char a) {
return __builtin_elementwise_bitreverse(a);
}
signed short f3(signed short a) {
return __builtin_elementwise_bitreverse(a);
}for the define dso_local noundef zeroext i8 @<!-- -->f(unsigned char)(i8 noundef zeroext %a) local_unnamed_addr {
entry:
tail call void @<!-- -->llvm.dbg.value(metadata i8 %a, metadata !16, metadata !DIExpression())
ret i8 0
}Based on the documentation: https://clang.llvm.org/docs/LanguageExtensions.html This is not expected behavior. |
|
If I look closer the documentation does say the implementation is incomplete but does not specify:
but nothing indicates it should not work w/ |
|
CC @frasercrmck who hit this in #119423 |
|
@llvm/issue-subscribers-clang-frontend Author: Shafik Yaghmour (shafik)
Given the following: https://godbolt.org/z/M1hEqs9q5
unsigned char f(unsigned char a) {
return __builtin_elementwise_bitreverse(a);
}
unsigned short f(unsigned short a) {
return __builtin_elementwise_bitreverse(a);
}
signed char f3(signed char a) {
return __builtin_elementwise_bitreverse(a);
}
signed short f3(signed short a) {
return __builtin_elementwise_bitreverse(a);
}for the define dso_local noundef zeroext i8 @<!-- -->f(unsigned char)(i8 noundef zeroext %a) local_unnamed_addr {
entry:
tail call void @<!-- -->llvm.dbg.value(metadata i8 %a, metadata !16, metadata !DIExpression())
ret i8 0
}Based on the documentation: https://clang.llvm.org/docs/LanguageExtensions.html This is not expected behavior. |
) This commit restricts the use of scalar types in vector math builtins, particularly the `__builtin_elementwise_*` builtins. Previously, small scalar integer types would be promoted to `int`, as per the usual conversions. This would silently do the wrong thing for certain operations, such as `add_sat`, `popcount`, `bitreverse`, and others. Similarly, since unsigned integer types were promoted to `int`, something like `add_sat(unsigned char, unsigned char)` would perform a *signed* operation. With this patch, promotable scalar integer types are not promoted to int, and are kept intact. If any of the types differ in the binary and ternary builtins, an error is issued. Similarly an error is issued if builtins are supplied integer types of different signs. Mixing enums of different types in binary/ternary builtins now consistently raises an error in all language modes. This brings the behaviour surrounding scalar types more in line with that of vector types. No change is made to vector types, which are both not promoted and whose element types must match. Fixes llvm#84047. RFC: https://discourse.llvm.org/t/rfc-change-behaviour-of-elementwise-builtins-on-scalar-integer-types/83725
) This commit restricts the use of scalar types in vector math builtins, particularly the `__builtin_elementwise_*` builtins. Previously, small scalar integer types would be promoted to `int`, as per the usual conversions. This would silently do the wrong thing for certain operations, such as `add_sat`, `popcount`, `bitreverse`, and others. Similarly, since unsigned integer types were promoted to `int`, something like `add_sat(unsigned char, unsigned char)` would perform a *signed* operation. With this patch, promotable scalar integer types are not promoted to int, and are kept intact. If any of the types differ in the binary and ternary builtins, an error is issued. Similarly an error is issued if builtins are supplied integer types of different signs. Mixing enums of different types in binary/ternary builtins now consistently raises an error in all language modes. This brings the behaviour surrounding scalar types more in line with that of vector types. No change is made to vector types, which are both not promoted and whose element types must match. Fixes llvm#84047. RFC: https://discourse.llvm.org/t/rfc-change-behaviour-of-elementwise-builtins-on-scalar-integer-types/83725
) This commit restricts the use of scalar types in vector math builtins, particularly the `__builtin_elementwise_*` builtins. Previously, small scalar integer types would be promoted to `int`, as per the usual conversions. This would silently do the wrong thing for certain operations, such as `add_sat`, `popcount`, `bitreverse`, and others. Similarly, since unsigned integer types were promoted to `int`, something like `add_sat(unsigned char, unsigned char)` would perform a *signed* operation. With this patch, promotable scalar integer types are not promoted to int, and are kept intact. If any of the types differ in the binary and ternary builtins, an error is issued. Similarly an error is issued if builtins are supplied integer types of different signs. Mixing enums of different types in binary/ternary builtins now consistently raises an error in all language modes. This brings the behaviour surrounding scalar types more in line with that of vector types. No change is made to vector types, which are both not promoted and whose element types must match. Fixes llvm#84047. RFC: https://discourse.llvm.org/t/rfc-change-behaviour-of-elementwise-builtins-on-scalar-integer-types/83725
Given the following: https://godbolt.org/z/M1hEqs9q5
for the
unsigned charandunsigned shortcases it automatically returns0w/ any level of optimization e.g.Based on the documentation: https://clang.llvm.org/docs/LanguageExtensions.html
This is not expected behavior.
The text was updated successfully, but these errors were encountered: