mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-26 09:36:08 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/clang/test/CodeGen/ext-int-sanitizer.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

312 lines
14 KiB
C++
Raw Normal View History

[CodeGen] Convert tests to opaque pointers (NFC) Conversion performed using the script at: https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34 These are only tests where no manual fixup was required.
2022-10-07 14:09:44 +02:00
// RUN: %clang_cc1 -triple x86_64-gnu-linux -fsanitize=array-bounds,enum,float-cast-overflow,integer-divide-by-zero,implicit-unsigned-integer-truncation,implicit-signed-integer-truncation,implicit-integer-sign-change,unsigned-integer-overflow,signed-integer-overflow,shift-base,shift-exponent -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:46:54 -05:00
// CHECK: define{{.*}} void @_Z6BoundsRA10_KiDB15_
void Bounds(const int (&Array)[10], _BitInt(15) Index) {
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
int I1 = Array[Index];
// CHECK: %[[SEXT:.+]] = sext i15 %{{.+}} to i64
// CHECK: %[[CMP:.+]] = icmp ult i64 %[[SEXT]], 10
// CHECK: br i1 %[[CMP]]
// CHECK: call void @__ubsan_handle_out_of_bounds
}
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 00:27:11 -08:00
// CHECK: define{{.*}} void @_Z4Enumv
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
void Enum() {
enum E1 { e1a = 0, e1b = 127 }
e1;
enum E2 { e2a = -1, e2b = 64 }
e2;
enum E3 { e3a = (1u << 31) - 1 }
e3;
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:46:54 -05:00
_BitInt(34) a = e1;
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[E1:.+]] = icmp ule i32 %{{.*}}, 127
// CHECK: br i1 %[[E1]]
// CHECK: call void @__ubsan_handle_load_invalid_value_abort
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:46:54 -05:00
_BitInt(34) b = e2;
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[E2HI:.*]] = icmp sle i32 {{.*}}, 127
// CHECK: %[[E2LO:.*]] = icmp sge i32 {{.*}}, -128
// CHECK: %[[E2:.*]] = and i1 %[[E2HI]], %[[E2LO]]
// CHECK: br i1 %[[E2]]
// CHECK: call void @__ubsan_handle_load_invalid_value_abort
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:46:54 -05:00
_BitInt(34) c = e3;
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[E3:.*]] = icmp ule i32 {{.*}}, 2147483647
// CHECK: br i1 %[[E3]]
// CHECK: call void @__ubsan_handle_load_invalid_value_abort
}
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 00:27:11 -08:00
// CHECK: define{{.*}} void @_Z13FloatOverflowfd
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
void FloatOverflow(float f, double d) {
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:46:54 -05:00
_BitInt(10) E = f;
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: fcmp ogt float %{{.+}}, -5.130000e+02
// CHECK: fcmp olt float %{{.+}}, 5.120000e+02
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:46:54 -05:00
_BitInt(10) E2 = d;
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: fcmp ogt double %{{.+}}, -5.130000e+02
// CHECK: fcmp olt double %{{.+}}, 5.120000e+02
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:46:54 -05:00
_BitInt(7) E3 = f;
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: fcmp ogt float %{{.+}}, -6.500000e+01
// CHECK: fcmp olt float %{{.+}}, 6.400000e+01
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:46:54 -05:00
_BitInt(7) E4 = d;
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: fcmp ogt double %{{.+}}, -6.500000e+01
// CHECK: fcmp olt double %{{.+}}, 6.400000e+01
}
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:46:54 -05:00
// CHECK: define{{.*}} void @_Z14UIntTruncationDU35_jy
void UIntTruncation(unsigned _BitInt(35) E, unsigned int i, unsigned long long ll) {
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
i = E;
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[LOADE:.+]] = load i64
// CHECK: %[[E1:.+]] = trunc i64 %[[LOADE]] to i35
// CHECK: %[[STOREDV:.+]] = zext i35 %[[E1]] to i64
// CHECK: store i64 %[[STOREDV]], ptr %[[EADDR:.+]]
// CHECK: %[[LOADE2:.+]] = load i64, ptr %[[EADDR]]
// CHECK: %[[LOADEDV:.+]] = trunc i64 %[[LOADE2]] to i35
// CHECK: %[[CONV:.+]] = trunc i35 %[[LOADEDV]] to i32
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[EXT:.+]] = zext i32 %[[CONV]] to i35
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[CHECK:.+]] = icmp eq i35 %[[EXT]], %[[LOADEDV]]
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: br i1 %[[CHECK]]
// CHECK: call void @__ubsan_handle_implicit_conversion_abort
E = ll;
// CHECK: %[[LOADLL:.+]] = load i64
// CHECK: %[[CONV:.+]] = trunc i64 %[[LOADLL]] to i35
// CHECK: %[[EXT:.+]] = zext i35 %[[CONV]] to i64
// CHECK: %[[CHECK:.+]] = icmp eq i64 %[[EXT]], %[[LOADLL]]
// CHECK: br i1 %[[CHECK]]
// CHECK: call void @__ubsan_handle_implicit_conversion_abort
}
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:46:54 -05:00
// CHECK: define{{.*}} void @_Z13IntTruncationDB35_DU42_ij
void IntTruncation(_BitInt(35) E, unsigned _BitInt(42) UE, int i, unsigned j) {
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
j = E;
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[LOADE:.+]] = load i64
// CHECK: %[[E1:.+]] = trunc i64 %[[LOADE]] to i35
// CHECK: %[[STOREDV:.+]] = sext i35 %[[E1]] to i64
// CHECK: store i64 %[[STOREDV]], ptr %[[EADDR:.+]]
// CHECK: %[[LOADE2:.+]] = load i64, ptr %[[EADDR]]
// CHECK: %[[LOADEDV:.+]] = trunc i64 %[[LOADE2]] to i35
// CHECK: %[[CONV:.+]] = trunc i35 %[[LOADEDV]] to i32
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[EXT:.+]] = zext i32 %[[CONV]] to i35
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[CHECK:.+]] = icmp eq i35 %[[EXT]], %[[LOADEDV]]
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: br i1 %[[CHECK]]
// CHECK: call void @__ubsan_handle_implicit_conversion_abort
j = UE;
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[LOADUE:.+]] = load i64
// CHECK: %[[LOADEDV:.+]] = trunc i64 %[[LOADUE]] to i42
// CHECK: %[[CONV:.+]] = trunc i42 %[[LOADEDV]] to i32
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[EXT:.+]] = zext i32 %[[CONV]] to i42
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[CHECK:.+]] = icmp eq i42 %[[EXT]], %[[LOADEDV]]
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: br i1 %[[CHECK]]
// CHECK: call void @__ubsan_handle_implicit_conversion_abort
// Note: also triggers sign change check.
i = UE;
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[LOADUE:.+]] = load i64
// CHECK: %[[LOADEDV:.+]] = trunc i64 %[[LOADUE]] to i42
// CHECK: %[[CONV:.+]] = trunc i42 %[[LOADEDV]] to i32
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[NEG:.+]] = icmp slt i32 %[[CONV]], 0
// CHECK: %[[SIGNCHECK:.+]] = icmp eq i1 false, %[[NEG]]
// CHECK: %[[EXT:.+]] = sext i32 %[[CONV]] to i42
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[CHECK:.+]] = icmp eq i42 %[[EXT]], %[[LOADEDV]]
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[CHECKBOTH:.+]] = and i1 %[[SIGNCHECK]], %[[CHECK]]
// CHECK: br i1 %[[CHECKBOTH]]
// CHECK: call void @__ubsan_handle_implicit_conversion_abort
// Note: also triggers sign change check.
E = UE;
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[LOADUE:.+]] = load i64
// CHECK: %[[LOADEDV:.+]] = trunc i64 %[[LOADUE]] to i42
// CHECK: %[[CONV:.+]] = trunc i42 %[[LOADEDV]] to i35
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[NEG:.+]] = icmp slt i35 %[[CONV]], 0
// CHECK: %[[SIGNCHECK:.+]] = icmp eq i1 false, %[[NEG]]
// CHECK: %[[EXT:.+]] = sext i35 %[[CONV]] to i42
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[CHECK:.+]] = icmp eq i42 %[[EXT]], %[[LOADEDV]]
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[CHECKBOTH:.+]] = and i1 %[[SIGNCHECK]], %[[CHECK]]
// CHECK: br i1 %[[CHECKBOTH]]
// CHECK: call void @__ubsan_handle_implicit_conversion_abort
}
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:46:54 -05:00
// CHECK: define{{.*}} void @_Z15SignChangeCheckDU39_DB39_
void SignChangeCheck(unsigned _BitInt(39) UE, _BitInt(39) E) {
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
UE = E;
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[LOADEU:.+]] = load i64
// CHECK: %[[LOADE:.+]] = load i64
// CHECK: %[[LOADEDV:.+]] = trunc i64 %[[LOADE]] to i39
// CHECK: %[[STOREDV:.+]] = sext i39 %[[LOADEDV]] to i64
// CHECK: store i64 %[[STOREDV]], ptr %[[EADDR:.+]]
// CHECK: %[[LOADE2:.+]] = load i64, ptr %[[EADDR]]
// CHECK: %[[LOADEDV2:.+]] = trunc i64 %[[LOADE2]] to i39
// CHECK: %[[NEG:.+]] = icmp slt i39 %[[LOADEDV2]], 0
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[SIGNCHECK:.+]] = icmp eq i1 %[[NEG]], false
// CHECK: br i1 %[[SIGNCHECK]]
// CHECK: call void @__ubsan_handle_implicit_conversion_abort
E = UE;
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[STOREDV2:.+]] = zext i39 %[[LOADEDV2]] to i64
// CHECK: store i64 %[[STOREDV2]], ptr %[[UEADDR:.+]]
// CHECK: %[[LOADUE2:.+]] = load i64, ptr %[[UEADDR]]
// CHECK: %[[LOADEDV3:.+]] = trunc i64 %[[LOADUE2]] to i39
// CHECK: %[[NEG:.+]] = icmp slt i39 %[[LOADEDV3]], 0
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[SIGNCHECK:.+]] = icmp eq i1 false, %[[NEG]]
// CHECK: br i1 %[[SIGNCHECK]]
// CHECK: call void @__ubsan_handle_implicit_conversion_abort
}
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:46:54 -05:00
// CHECK: define{{.*}} void @_Z9DivByZeroDB11_i
void DivByZero(_BitInt(11) E, int i) {
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// Also triggers signed integer overflow.
E / E;
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[EADDR:.+]] = alloca i16
// CHECK: %[[E:.+]] = load i16, ptr %[[EADDR]]
// CHECK: %[[LOADEDE:.+]] = trunc i16 %[[E]] to i11
// CHECK: %[[E2:.+]] = load i16, ptr %[[EADDR]]
// CHECK: %[[LOADEDE2:.+]] = trunc i16 %[[E2]] to i11
// CHECK: %[[NEZERO:.+]] = icmp ne i11 %[[LOADEDE2]], 0
// CHECK: %[[NEMIN:.+]] = icmp ne i11 %[[LOADEDE]], -1024
// CHECK: %[[NENEG1:.+]] = icmp ne i11 %[[LOADEDE2]], -1
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[OR:.+]] = or i1 %[[NEMIN]], %[[NENEG1]]
// CHECK: %[[AND:.+]] = and i1 %[[NEZERO]], %[[OR]]
// CHECK: br i1 %[[AND]]
// CHECK: call void @__ubsan_handle_divrem_overflow_abort
}
// TODO:
//-fsanitize=shift: (shift-base, shift-exponent) Shift operators where the amount shifted is greater or equal to the promoted bit-width of the left hand side or less than zero, or where the left hand side is negative. For a signed left shift, also checks for signed overflow in C, and for unsigned overflow in C++. You can use -fsanitize=shift-base or -fsanitize=shift-exponent to check only left-hand side or right-hand side of shift operation, respectively.
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:46:54 -05:00
// CHECK: define{{.*}} void @_Z6ShiftsDB9_
void Shifts(_BitInt(9) E) {
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
E >> E;
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[EADDR:.+]] = alloca i16
// CHECK: %[[LHSE:.+]] = load i16, ptr %[[EADDR]]
// CHECK: %[[RHSE:.+]] = load i16, ptr %[[EADDR]]
// CHECK: %[[LOADED:.+]] = trunc i16 %[[RHSE]] to i9
// CHECK: %[[CMP:.+]] = icmp ule i9 %[[LOADED]], 8
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: br i1 %[[CMP]]
// CHECK: call void @__ubsan_handle_shift_out_of_bounds_abort
E << E;
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[LHSE:.+]] = load i16, ptr
// CHECK: %[[LOADEDL:.+]] = trunc i16 %[[LHSE]] to i9
// CHECK: %[[RHSE:.+]] = load i16, ptr
// CHECK: %[[LOADED:.+]] = trunc i16 %[[RHSE]] to i9
// CHECK: %[[CMP:.+]] = icmp ule i9 %[[LOADED]], 8
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: br i1 %[[CMP]]
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[ZEROS:.+]] = sub nuw nsw i9 8, %[[LOADED]]
// CHECK: %[[CHECK:.+]] = lshr i9 %[[LOADEDL]], %[[ZEROS]]
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[SKIPSIGN:.+]] = lshr i9 %[[CHECK]], 1
// CHECK: %[[CHECK:.+]] = icmp eq i9 %[[SKIPSIGN]]
// CHECK: %[[PHI:.+]] = phi i1 [ true, %{{.+}} ], [ %[[CHECK]], %{{.+}} ]
// CHECK: and i1 %[[CMP]], %[[PHI]]
// CHECK: call void @__ubsan_handle_shift_out_of_bounds_abort
}
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:46:54 -05:00
// CHECK: define{{.*}} void @_Z21SignedIntegerOverflowDB93_DB4_DB31_
void SignedIntegerOverflow(_BitInt(93) BiggestE,
_BitInt(4) SmallestE,
_BitInt(31) JustRightE) {
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
BiggestE + BiggestE;
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[LOADBIGGESTE2:.+]] = load i128
// CHECK: %[[LOADEDV:.+]] = trunc i128 %[[LOADBIGGESTE2]] to i93
// CHECK: %[[STOREDV:.+]] = sext i93 %[[LOADEDV]] to i128
// CHECK: store i128 %[[STOREDV]], ptr %[[BIGGESTEADDR:.+]]
// CHECK: %[[LOAD1:.+]] = load i128, ptr %[[BIGGESTEADDR]]
// CHECK: %[[LOADEDV1:.+]] = trunc i128 %[[LOAD1]] to i93
// CHECK: %[[LOAD2:.+]] = load i128, ptr %[[BIGGESTEADDR]]
// CHECK: %[[LOADEDV2:.+]] = trunc i128 %[[LOAD2]] to i93
// CHECK: %[[OFCALL:.+]] = call { i93, i1 } @llvm.sadd.with.overflow.i93(i93 %[[LOADEDV1]], i93 %[[LOADEDV2]])
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[EXRESULT:.+]] = extractvalue { i93, i1 } %[[OFCALL]], 0
// CHECK: %[[OFRESULT:.+]] = extractvalue { i93, i1 } %[[OFCALL]], 1
// CHECK: %[[CHECK:.+]] = xor i1 %[[OFRESULT]], true
// CHECK: br i1 %[[CHECK]]
// CHECK: call void @__ubsan_handle_add_overflow_abort
SmallestE - SmallestE;
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[LOAD1:.+]] = load i8, ptr
// CHECK: %[[LOADEDV1:.+]] = trunc i8 %[[LOAD1]] to i4
// CHECK: %[[LOAD2:.+]] = load i8, ptr
// CHECK: %[[LOADEDV2:.+]] = trunc i8 %[[LOAD2]] to i4
// CHECK: %[[OFCALL:.+]] = call { i4, i1 } @llvm.ssub.with.overflow.i4(i4 %[[LOADEDV1]], i4 %[[LOADEDV2]])
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[EXRESULT:.+]] = extractvalue { i4, i1 } %[[OFCALL]], 0
// CHECK: %[[OFRESULT:.+]] = extractvalue { i4, i1 } %[[OFCALL]], 1
// CHECK: %[[CHECK:.+]] = xor i1 %[[OFRESULT]], true
// CHECK: br i1 %[[CHECK]]
// CHECK: call void @__ubsan_handle_sub_overflow_abort
JustRightE * JustRightE;
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[LOAD1:.+]] = load i32, ptr
// CHECK: %[[LOADEDV1:.+]] = trunc i32 %[[LOAD1]] to i31
// CHECK: %[[LOAD2:.+]] = load i32, ptr
// CHECK: %[[LOADEDV2:.+]] = trunc i32 %[[LOAD2]] to i31
// CHECK: %[[OFCALL:.+]] = call { i31, i1 } @llvm.smul.with.overflow.i31(i31 %[[LOADEDV1]], i31 %[[LOADEDV2]])
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[EXRESULT:.+]] = extractvalue { i31, i1 } %[[OFCALL]], 0
// CHECK: %[[OFRESULT:.+]] = extractvalue { i31, i1 } %[[OFCALL]], 1
// CHECK: %[[CHECK:.+]] = xor i1 %[[OFRESULT]], true
// CHECK: br i1 %[[CHECK]]
// CHECK: call void @__ubsan_handle_mul_overflow_abort
}
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:46:54 -05:00
// CHECK: define{{.*}} void @_Z23UnsignedIntegerOverflowjDU23_DU35_
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
void UnsignedIntegerOverflow(unsigned u,
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:46:54 -05:00
unsigned _BitInt(23) SmallE,
unsigned _BitInt(35) BigE) {
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
u = SmallE + SmallE;
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[LOADE1:.+]] = load i32, ptr
// CHECK-NEXT: %[[LOADEDV1:.+]] = trunc i32 %[[LOADE1]] to i23
// CHECK: %[[LOADE2:.+]] = load i32, ptr
// CHECK-NEXT: %[[LOADEDV2:.+]] = trunc i32 %[[LOADE2]] to i23
// CHECK: %[[OFCALL:.+]] = call { i23, i1 } @llvm.uadd.with.overflow.i23(i23 %[[LOADEDV1]], i23 %[[LOADEDV2]])
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[EXRESULT:.+]] = extractvalue { i23, i1 } %[[OFCALL]], 0
// CHECK: %[[OFRESULT:.+]] = extractvalue { i23, i1 } %[[OFCALL]], 1
// CHECK: %[[CHECK:.+]] = xor i1 %[[OFRESULT]], true
// CHECK: br i1 %[[CHECK]]
// CHECK: call void @__ubsan_handle_add_overflow_abort
SmallE = u + u;
[CodeGen] Convert tests to opaque pointers (NFC) Conversion performed using the script at: https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34 These are only tests where no manual fixup was required.
2022-10-07 14:09:44 +02:00
// CHECK: %[[LOADU1:.+]] = load i32, ptr
// CHECK: %[[LOADU2:.+]] = load i32, ptr
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[OFCALL:.+]] = call { i32, i1 } @llvm.uadd.with.overflow.i32(i32 %[[LOADU1]], i32 %[[LOADU2]])
// CHECK: %[[EXRESULT:.+]] = extractvalue { i32, i1 } %[[OFCALL]], 0
// CHECK: %[[OFRESULT:.+]] = extractvalue { i32, i1 } %[[OFCALL]], 1
// CHECK: %[[CHECK:.+]] = xor i1 %[[OFRESULT]], true
// CHECK: br i1 %[[CHECK]]
// CHECK: call void @__ubsan_handle_add_overflow_abort
SmallE = SmallE + SmallE;
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[LOADE1:.+]] = load i32, ptr
// CHECK-NEXT: %[[LOADEDV1:.+]] = trunc i32 %[[LOADE1]] to i23
// CHECK: %[[LOADE2:.+]] = load i32, ptr
// CHECK-NEXT: %[[LOADEDV2:.+]] = trunc i32 %[[LOADE2]] to i23
// CHECK: %[[OFCALL:.+]] = call { i23, i1 } @llvm.uadd.with.overflow.i23(i23 %[[LOADEDV1]], i23 %[[LOADEDV2]])
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[EXRESULT:.+]] = extractvalue { i23, i1 } %[[OFCALL]], 0
// CHECK: %[[OFRESULT:.+]] = extractvalue { i23, i1 } %[[OFCALL]], 1
// CHECK: %[[CHECK:.+]] = xor i1 %[[OFRESULT]], true
// CHECK: br i1 %[[CHECK]]
// CHECK: call void @__ubsan_handle_add_overflow_abort
SmallE = BigE + BigE;
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[LOADE1:.+]] = load i64, ptr
// CHECK-NEXT: %[[LOADEDV1:.+]] = trunc i64 %[[LOADE1]] to i35
// CHECK: %[[LOADE2:.+]] = load i64, ptr
// CHECK-NEXT: %[[LOADEDV2:.+]] = trunc i64 %[[LOADE2]] to i35
// CHECK: %[[OFCALL:.+]] = call { i35, i1 } @llvm.uadd.with.overflow.i35(i35 %[[LOADEDV1]], i35 %[[LOADEDV2]])
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[EXRESULT:.+]] = extractvalue { i35, i1 } %[[OFCALL]], 0
// CHECK: %[[OFRESULT:.+]] = extractvalue { i35, i1 } %[[OFCALL]], 1
// CHECK: %[[CHECK:.+]] = xor i1 %[[OFRESULT]], true
// CHECK: br i1 %[[CHECK]]
// CHECK: call void @__ubsan_handle_add_overflow_abort
BigE = BigE + BigE;
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364) There are two problems with _BitInt prior to this patch: 1. For at least some values of N, we cannot use LLVM's iN for the type of struct elements, array elements, allocas, global variables, and so on, because the LLVM layout for that type does not match the high-level layout of _BitInt(N). Example: Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both, since we have now correct implementation of __int128 in place after a21abc7. When this happens, opaque [M x i8] types used, where M = sizeof(_BitInt(N)). 2. LLVM doesn't guarantee any particular extension behavior for integer types that aren't a multiple of 8. For this reason, all _BitInt types are now have in-memory representation that is a whole number of bytes. I.e. for example _BitInt(17) now will have memory layout type i32. This patch also introduces concept of load/store type and adds an API to CodeGenTypes that returns the IR type that should be used for load and store operations. This is particularly useful for the case when a _BitInt ends up having array of bytes as memory layout type. For _BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and stores of iM would both (1) produce far better code from the backends and (2) be far more optimizable by IR passes than loads and stores of [M x i8]. Fixes https://github.com/llvm/llvm-project/issues/85139 Fixes https://github.com/llvm/llvm-project/issues/83419 --------- Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
// CHECK: %[[LOADE1:.+]] = load i64, ptr
// CHECK-NEXT: %[[LOADEDV1:.+]] = trunc i64 %[[LOADE1]] to i35
// CHECK: %[[LOADE2:.+]] = load i64, ptr
// CHECK-NEXT: %[[LOADEDV2:.+]] = trunc i64 %[[LOADE2]] to i35
// CHECK: %[[OFCALL:.+]] = call { i35, i1 } @llvm.uadd.with.overflow.i35(i35 %[[LOADEDV1]], i35 %[[LOADEDV2]])
Reland Implement _ExtInt as an extended int type specifier. I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17 10:44:19 -07:00
// CHECK: %[[EXRESULT:.+]] = extractvalue { i35, i1 } %[[OFCALL]], 0
// CHECK: %[[OFRESULT:.+]] = extractvalue { i35, i1 } %[[OFCALL]], 1
// CHECK: %[[CHECK:.+]] = xor i1 %[[OFRESULT]], true
// CHECK: br i1 %[[CHECK]]
// CHECK: call void @__ubsan_handle_add_overflow_abort
}
Reference in New Issue Copy Permalink