mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-27 08:06:07 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/clang/test/CodeGen/ext-int-cc.c

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

330 lines
24 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 -no-enable-noundef-analysis -triple x86_64-gnu-linux -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=LIN64
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple x86_64-windows-pc -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=WIN64
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple i386-gnu-linux -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=LIN32
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple i386-windows-pc -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=WIN32
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple nvptx64 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=NVPTX64
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple nvptx -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=NVPTX
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple sparcv9 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=SPARCV9
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple sparc -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=SPARC
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple mips64 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=MIPS64
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple mips -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=MIPS
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple spir64 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=SPIR64
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple spir -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=SPIR
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple hexagon -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=HEX
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple lanai -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=LANAI
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple r600 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=R600
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple arc -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=ARC
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple xcore -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=XCORE
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple riscv64 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=RISCV64
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple riscv32 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=RISCV32
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple wasm64 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=WASM
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple wasm32 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=WASM
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple systemz -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=SYSTEMZ
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple ppc64 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=PPC64
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple ppc -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=PPC32
[Clang] Fix incorrect passing of _BitInt args (#90741) This patch removes incorrect `byval` attribute from pointer argument passed with >128 bit long _BitInt types.
2024-05-15 10:51:32 +01:00
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple aarch64 -O3 -disable-llvm-passes -fexperimental-max-bitint-width=1024 -emit-llvm -o - %s | FileCheck %s --check-prefixes=AARCH64
[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 -no-enable-noundef-analysis -triple aarch64 -target-abi darwinpcs -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=AARCH64DARWIN
[Clang] Fix incorrect passing of _BitInt args (#90741) This patch removes incorrect `byval` attribute from pointer argument passed with >128 bit long _BitInt types.
2024-05-15 10:51:32 +01:00
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple arm64_32-apple-ios -O3 -disable-llvm-passes -fexperimental-max-bitint-width=1024 -emit-llvm -o - %s | FileCheck %s --check-prefixes=AARCH64
[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 -no-enable-noundef-analysis -triple arm64_32-apple-ios -target-abi darwinpcs -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=AARCH64DARWIN
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple arm -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=ARM
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple loongarch64 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=LA64
// RUN: %clang_cc1 -no-enable-noundef-analysis -triple loongarch32 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=LA32
[NFC] Split ext-int calling convention tests into their own file. I'm currently auditing all of the calling convention implications of _ExtInt for all platforms, so splitting them up into their own test will make this a much easier task to organize.
2020-04-29 12:18:59 -07:00
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
// Make sure 128 and 64 bit versions are passed like integers.
void ParamPassing(_BitInt(128) b, _BitInt(64) c) {}
// LIN64: define{{.*}} void @ParamPassing(i64 %{{.+}}, i64 %{{.+}}, i64 %{{.+}})
[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
// WIN64: define dso_local void @ParamPassing(ptr %{{.+}}, i64 %{{.+}})
// LIN32: define{{.*}} void @ParamPassing(ptr %{{.+}}, i64 %{{.+}})
// WIN32: define dso_local void @ParamPassing(ptr %{{.+}}, i64 %{{.+}})
// NACL: define{{.*}} void @ParamPassing(ptr byval(i128) align 8 %{{.+}}, i64 %{{.+}})
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
// NVPTX64: define{{.*}} void @ParamPassing(i128 %{{.+}}, i64 %{{.+}})
[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
// NVPTX: define{{.*}} void @ParamPassing(ptr byval(i128) align 8 %{{.+}}, i64 %{{.+}})
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
// SPARCV9: define{{.*}} void @ParamPassing(i128 %{{.+}}, i64 %{{.+}})
[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
// SPARC: define{{.*}} void @ParamPassing(ptr byval(i128) align 8 %{{.+}}, i64 %{{.+}})
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
// MIPS64: define{{.*}} void @ParamPassing(i128 signext %{{.+}}, i64 signext %{{.+}})
[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
// MIPS: define{{.*}} void @ParamPassing(ptr byval(i128) align 8 %{{.+}}, i64 signext %{{.+}})
// SPIR64: define{{.*}} spir_func void @ParamPassing(ptr byval(i128) align 8 %{{.+}}, i64 %{{.+}})
// SPIR: define{{.*}} spir_func void @ParamPassing(ptr byval(i128) align 8 %{{.+}}, i64 %{{.+}})
// HEX: define{{.*}} void @ParamPassing(ptr byval(i128) align 8 %{{.+}}, i64 %{{.+}})
// LANAI: define{{.*}} void @ParamPassing(ptr byval(i128) align 4 %{{.+}}, i64 %{{.+}})
// R600: define{{.*}} void @ParamPassing(ptr addrspace(5) byval(i128) align 8 %{{.+}}, i64 %{{.+}})
// ARC: define{{.*}} void @ParamPassing(ptr byval(i128) align 4 %{{.+}}, i64 inreg %{{.+}})
// XCORE: define{{.*}} void @ParamPassing(ptr byval(i128) align 4 %{{.+}}, i64 %{{.+}})
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
// RISCV64: define{{.*}} void @ParamPassing(i128 %{{.+}}, i64 %{{.+}})
[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
// RISCV32: define{{.*}} void @ParamPassing(ptr %{{.+}}, i64 %{{.+}})
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
// WASM: define{{.*}} void @ParamPassing(i128 %{{.+}}, i64 %{{.+}})
[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
// SYSTEMZ: define{{.*}} void @ParamPassing(ptr %{{.+}}, i64 %{{.+}})
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
// PPC64: define{{.*}} void @ParamPassing(i128 %{{.+}}, i64 %{{.+}})
[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
// PPC32: define{{.*}} void @ParamPassing(ptr byval(i128) align 8 %{{.+}}, i64 %{{.+}})
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
// AARCH64: define{{.*}} void @ParamPassing(i128 %{{.+}}, i64 %{{.+}})
// AARCH64DARWIN: define{{.*}} void @ParamPassing(i128 %{{.+}}, i64 %{{.+}})
[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
// ARM: define{{.*}} arm_aapcscc void @ParamPassing(ptr byval(i128) align 8 %{{.+}}, i64 %{{.+}})
[Clang][LoongArch] Implement ABI lowering Reuse most of RISCV's implementation with several exceptions: 1. Assign signext/zeroext attribute to args passed in stack. On RISCV, integer scalars passed in registers have signext/zeroext when promoted, but are anyext if passed on the stack. This is defined in early RISCV ABI specification. But after this change [1], integers should also be signext/zeroext if passed on the stack. So I think RISCV's ABI lowering should be updated [2]. While in LoongArch ABI spec, we can see that integer scalars narrower than GRLEN bits are zero/sign-extended no matter passed in registers or on the stack. 2. Zero-width bit fields are ignored. This matches GCC's behavior but it hasn't been documented in ABI sepc. See https://gcc.gnu.org/r12-8294. 3. `char` is signed by default. There is another difference worth mentioning is that `char` is signed by default on LoongArch while it is unsigned on RISCV. This patch also adds `_BitInt` type support to LoongArch and handle it in LoongArchABIInfo::classifyArgumentType. [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/cec39a064ee0e5b0129973fffab7e3ad1710498f [2] https://github.com/llvm/llvm-project/issues/57261 Differential Revision: https://reviews.llvm.org/D132285
2022-09-19 10:23:21 +08:00
// LA64: define{{.*}} void @ParamPassing(i128 %{{.+}}, i64 %{{.+}})
[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
// LA32: define{{.*}} void @ParamPassing(ptr %{{.+}}, i64 %{{.+}})
Implement _ExtInt ABI for all ABIs in Clang, enable type for ABIs This is the result of an audit of all of the ABIs in clang to implement and enable the type for those targets. Additionally, this finds an issue with integer-promotion passing for a few platforms when using _ExtInt of < int, so this also corrects that resulting in signext/zeroext being on a params of those types in some platforms. Differential Revisions: https://reviews.llvm.org/D79118
2020-04-29 12:48:07 -07:00
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
void ParamPassing2(_BitInt(127) b, _BitInt(63) c) {}
// LIN64: define{{.*}} void @ParamPassing2(i64 %{{.+}}, i64 %{{.+}}, i64 %{{.+}})
[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
// WIN64: define dso_local void @ParamPassing2(ptr %{{.+}}, i63 %{{.+}})
// LIN32: define{{.*}} void @ParamPassing2(ptr %{{.+}}, i63 %{{.+}})
// WIN32: define dso_local void @ParamPassing2(ptr %{{.+}}, i63 %{{.+}})
[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
// NACL: define{{.*}} void @ParamPassing2(ptr byval(i128) align 8 %{{.+}}, i63 %{{.+}})
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
// NVPTX64: define{{.*}} void @ParamPassing2(i127 %{{.+}}, i63 %{{.+}})
[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
// NVPTX: define{{.*}} void @ParamPassing2(ptr byval(i128) align 8 %{{.+}}, i63 %{{.+}})
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
// SPARCV9: define{{.*}} void @ParamPassing2(i127 %{{.+}}, i63 signext %{{.+}})
[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
// SPARC: define{{.*}} void @ParamPassing2(ptr byval(i128) align 8 %{{.+}}, i63 %{{.+}})
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
// MIPS64: define{{.*}} void @ParamPassing2(i127 signext %{{.+}}, i63 signext %{{.+}})
[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
// MIPS: define{{.*}} void @ParamPassing2(ptr byval(i128) align 8 %{{.+}}, i63 signext %{{.+}})
// SPIR64: define{{.*}} spir_func void @ParamPassing2(ptr byval(i128) align 8 %{{.+}}, i63 %{{.+}})
// SPIR: define{{.*}} spir_func void @ParamPassing2(ptr byval(i128) align 8 %{{.+}}, i63 %{{.+}})
// HEX: define{{.*}} void @ParamPassing2(ptr byval(i128) align 8 %{{.+}}, i63 %{{.+}})
// LANAI: define{{.*}} void @ParamPassing2(ptr byval(i128) align 4 %{{.+}}, i63 %{{.+}})
// R600: define{{.*}} void @ParamPassing2(ptr addrspace(5) byval(i128) align 8 %{{.+}}, i63 %{{.+}})
// ARC: define{{.*}} void @ParamPassing2(ptr byval(i128) align 4 %{{.+}}, i63 inreg %{{.+}})
// XCORE: define{{.*}} void @ParamPassing2(ptr byval(i128) align 4 %{{.+}}, i63 %{{.+}})
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
// RISCV64: define{{.*}} void @ParamPassing2(i127 %{{.+}}, i63 signext %{{.+}})
[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
// RISCV32: define{{.*}} void @ParamPassing2(ptr %{{.+}}, i63 %{{.+}})
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
// WASM: define{{.*}} void @ParamPassing2(i127 %{{.+}}, i63 %{{.+}})
[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
// SYSTEMZ: define{{.*}} void @ParamPassing2(ptr %{{.+}}, i63 signext %{{.+}})
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
// PPC64: define{{.*}} void @ParamPassing2(i127 %{{.+}}, i63 signext %{{.+}})
[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
// PPC32: define{{.*}} void @ParamPassing2(ptr byval(i128) align 8 %{{.+}}, i63 %{{.+}})
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
// AARCH64: define{{.*}} void @ParamPassing2(i127 %{{.+}}, i63 %{{.+}})
// AARCH64DARWIN: define{{.*}} void @ParamPassing2(i127 %{{.+}}, i63 %{{.+}})
[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
// ARM: define{{.*}} arm_aapcscc void @ParamPassing2(ptr byval(i128) align 8 %{{.+}}, i63 %{{.+}})
[Clang][LoongArch] Implement ABI lowering Reuse most of RISCV's implementation with several exceptions: 1. Assign signext/zeroext attribute to args passed in stack. On RISCV, integer scalars passed in registers have signext/zeroext when promoted, but are anyext if passed on the stack. This is defined in early RISCV ABI specification. But after this change [1], integers should also be signext/zeroext if passed on the stack. So I think RISCV's ABI lowering should be updated [2]. While in LoongArch ABI spec, we can see that integer scalars narrower than GRLEN bits are zero/sign-extended no matter passed in registers or on the stack. 2. Zero-width bit fields are ignored. This matches GCC's behavior but it hasn't been documented in ABI sepc. See https://gcc.gnu.org/r12-8294. 3. `char` is signed by default. There is another difference worth mentioning is that `char` is signed by default on LoongArch while it is unsigned on RISCV. This patch also adds `_BitInt` type support to LoongArch and handle it in LoongArchABIInfo::classifyArgumentType. [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/cec39a064ee0e5b0129973fffab7e3ad1710498f [2] https://github.com/llvm/llvm-project/issues/57261 Differential Revision: https://reviews.llvm.org/D132285
2022-09-19 10:23:21 +08:00
// LA64: define{{.*}} void @ParamPassing2(i127 %{{.+}}, i63 signext %{{.+}})
[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
// LA32: define{{.*}} void @ParamPassing2(ptr %{{.+}}, i63 %{{.+}})
Implement _ExtInt ABI for all ABIs in Clang, enable type for ABIs This is the result of an audit of all of the ABIs in clang to implement and enable the type for those targets. Additionally, this finds an issue with integer-promotion passing for a few platforms when using _ExtInt of < int, so this also corrects that resulting in signext/zeroext being on a params of those types in some platforms. Differential Revisions: https://reviews.llvm.org/D79118
2020-04-29 12:48:07 -07:00
// Make sure we follow the signext rules for promotable integer types.
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
void ParamPassing3(_BitInt(15) a, _BitInt(31) b) {}
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// LIN64: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
Implement _ExtInt ABI for all ABIs in Clang, enable type for ABIs This is the result of an audit of all of the ABIs in clang to implement and enable the type for those targets. Additionally, this finds an issue with integer-promotion passing for a few platforms when using _ExtInt of < int, so this also corrects that resulting in signext/zeroext being on a params of those types in some platforms. Differential Revisions: https://reviews.llvm.org/D79118
2020-04-29 12:48:07 -07:00
// WIN64: define dso_local void @ParamPassing3(i15 %{{.+}}, i31 %{{.+}})
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// LIN32: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
Implement _ExtInt ABI for all ABIs in Clang, enable type for ABIs This is the result of an audit of all of the ABIs in clang to implement and enable the type for those targets. Additionally, this finds an issue with integer-promotion passing for a few platforms when using _ExtInt of < int, so this also corrects that resulting in signext/zeroext being on a params of those types in some platforms. Differential Revisions: https://reviews.llvm.org/D79118
2020-04-29 12:48:07 -07:00
// WIN32: define dso_local void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// NACL: define{{.*}} void @ParamPassing3(i15 %{{.+}}, i31 %{{.+}})
// NVPTX64: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
// NVPTX: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
// SPARCV9: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
// SPARC: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
// MIPS64: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
// MIPS: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
[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
// SPIR64: define{{.*}} spir_func void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
// SPIR: define{{.*}} spir_func void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// HEX: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
// LANAI: define{{.*}} void @ParamPassing3(i15 inreg %{{.+}}, i31 inreg %{{.+}})
// R600: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
// ARC: define{{.*}} void @ParamPassing3(i15 inreg signext %{{.+}}, i31 inreg signext %{{.+}})
// XCORE: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
// RISCV64: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
// RISCV32: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
// WASM: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
// SYSTEMZ: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
// PPC64: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
// PPC32: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
// AARCH64: define{{.*}} void @ParamPassing3(i15 %{{.+}}, i31 %{{.+}})
// AARCH64DARWIN: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
// ARM: define{{.*}} arm_aapcscc void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
[Clang][LoongArch] Implement ABI lowering Reuse most of RISCV's implementation with several exceptions: 1. Assign signext/zeroext attribute to args passed in stack. On RISCV, integer scalars passed in registers have signext/zeroext when promoted, but are anyext if passed on the stack. This is defined in early RISCV ABI specification. But after this change [1], integers should also be signext/zeroext if passed on the stack. So I think RISCV's ABI lowering should be updated [2]. While in LoongArch ABI spec, we can see that integer scalars narrower than GRLEN bits are zero/sign-extended no matter passed in registers or on the stack. 2. Zero-width bit fields are ignored. This matches GCC's behavior but it hasn't been documented in ABI sepc. See https://gcc.gnu.org/r12-8294. 3. `char` is signed by default. There is another difference worth mentioning is that `char` is signed by default on LoongArch while it is unsigned on RISCV. This patch also adds `_BitInt` type support to LoongArch and handle it in LoongArchABIInfo::classifyArgumentType. [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/cec39a064ee0e5b0129973fffab7e3ad1710498f [2] https://github.com/llvm/llvm-project/issues/57261 Differential Revision: https://reviews.llvm.org/D132285
2022-09-19 10:23:21 +08:00
// LA64: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
// LA32: define{{.*}} void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
Implement _ExtInt ABI for all ABIs in Clang, enable type for ABIs This is the result of an audit of all of the ABIs in clang to implement and enable the type for those targets. Additionally, this finds an issue with integer-promotion passing for a few platforms when using _ExtInt of < int, so this also corrects that resulting in signext/zeroext being on a params of those types in some platforms. Differential Revisions: https://reviews.llvm.org/D79118
2020-04-29 12:48:07 -07:00
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
#if __BITINT_MAXWIDTH__ > 128
// When supported, bit-precise types that are >128 are passed indirectly. Note,
// FileCheck doesn't pay attention to the preprocessor, so all of these tests
// are negated. This will give an error when a target does support larger
// _BitInt widths to alert us to enable the test.
void ParamPassing4(_BitInt(129) a) {}
[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
// LIN64: define{{.*}} void @ParamPassing4(ptr byval([24 x i8]) align 8 %{{.+}})
[X86][clang] Lift _BitInt() supported max width. Reviewed By: mgehre-amd Differential Revision: https://reviews.llvm.org/D139170
2022-12-06 10:19:12 +08:00
// WIN64: define dso_local void @ParamPassing4(ptr %{{.+}})
// LIN32: define{{.*}} void @ParamPassing4(ptr %{{.+}})
// WIN32: define dso_local void @ParamPassing4(ptr %{{.+}})
[Clang] Fix incorrect passing of _BitInt args (#90741) This patch removes incorrect `byval` attribute from pointer argument passed with >128 bit long _BitInt types.
2024-05-15 10:51:32 +01:00
// AARCH64: define{{.*}} void @ParamPassing4(ptr %{{.+}})
[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
// NACL-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
// NVPTX64-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
// NVPTX-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
// SPARCV9-NOT: define{{.*}} void @ParamPassing4(ptr %{{.+}})
// SPARC-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
// MIPS64-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
// MIPS-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
// SPIR64-NOT: define{{.*}} spir_func void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
// SPIR-NOT: define{{.*}} spir_func void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
// HEX-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
// LANAI-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 4 %{{.+}})
// R600-NOT: define{{.*}} void @ParamPassing4(ptr addrspace(5) byval(i129) align 8 %{{.+}})
// ARC-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 4 %{{.+}})
// XCORE-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 4 %{{.+}})
// RISCV64-NOT: define{{.*}} void @ParamPassing4(ptr %{{.+}})
// RISCV32-NOT: define{{.*}} void @ParamPassing4(ptr %{{.+}})
// WASM-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
// SYSTEMZ-NOT: define{{.*}} void @ParamPassing4(ptr %{{.+}})
// PPC64-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
// PPC32-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
// AARCH64DARWIN-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
// ARM-NOT: define{{.*}} arm_aapcscc void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
// LA64-NOT: define{{.*}} void @ParamPassing4(ptr %{{.+}})
// LA32-NOT: define{{.*}} void @ParamPassing4(ptr %{{.+}})
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
#endif
[Clang] [NFC] Fix unintended `-Wreturn-type` warnings everywhere in the test suite (#123464) In preparation of making `-Wreturn-type` default to an error (as there is virtually no situation where you’d *want* to fall off the end of a function that is supposed to return a value), this patch fixes tests that have relied on this being only a warning, of which there seem to be 3 kinds: 1. Tests which for no apparent reason have a function that triggers the warning. I suspect that a lot of these were on accident (or from before the warning was introduced), since a lot of people will open issues w/ their problematic code in the `main` function (which is the one case where you don’t need to return from a non-void function, after all...), which someone will then copy, possibly into a namespace, possibly renaming it, the end result of that being that you end up w/ something that definitely is not `main` anymore, but which still is declared as returning `int`, and which still has no return statement (another reason why I think this might apply to a lot of these is because usually the actual return type of such problematic functions is quite literally `int`). A lot of these are really old tests that don’t use `-verify`, which is why no-one noticed or had to care about the extra warning that was already being emitted by them until now. 2. Tests which test either `-Wreturn-type`, `[[noreturn]]`, or what codegen and sanitisers do whenever you do fall off the end of a function. 3. Tests where I struggle to figure out what is even being tested (usually because they’re Objective-C tests, and I don’t know Objective-C), whether falling off the end of a function matters in the first place, and tests where actually spelling out an expression to return would be rather cumbersome (e.g. matrix types currently don’t support list initialisation, so I can’t write e.g. `return {}`). For tests that fall into categories 2 and 3, I just added `-Wno-error=return-type` to the `RUN` lines and called it a day. This was especially necessary for the former since `-Wreturn-type` is an analysis-based warning, meaning that it is currently impossible to test for more than one occurrence of it in the same compilation if it defaults to an error since the analysis pass is skipped for subsequent functions as soon as an error is emitted. I’ve also added `-Werror=return-type` to a few tests that I had already updated as this patch was previously already making the warning an error by default, but we’ve decided to split that into two patches instead.
2025-01-18 19:16:33 +01:00
_BitInt(63) ReturnPassing(void) { return 0; }
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// LIN64: define{{.*}} i64 @ReturnPassing(
[NFC] Split ext-int calling convention tests into their own file. I'm currently auditing all of the calling convention implications of _ExtInt for all platforms, so splitting them up into their own test will make this a much easier task to organize.
2020-04-29 12:18:59 -07:00
// WIN64: define dso_local i63 @ReturnPassing(
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// LIN32: define{{.*}} i63 @ReturnPassing(
[NFC] Split ext-int calling convention tests into their own file. I'm currently auditing all of the calling convention implications of _ExtInt for all platforms, so splitting them up into their own test will make this a much easier task to organize.
2020-04-29 12:18:59 -07:00
// WIN32: define dso_local i63 @ReturnPassing(
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// NACL: define{{.*}} i63 @ReturnPassing(
// NVPTX64: define{{.*}} i63 @ReturnPassing(
// NVPTX: define{{.*}} i63 @ReturnPassing(
// SPARCV9: define{{.*}} signext i63 @ReturnPassing(
// SPARC: define{{.*}} i63 @ReturnPassing(
// MIPS64: define{{.*}} i63 @ReturnPassing(
// MIPS: define{{.*}} i63 @ReturnPassing(
[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
// SPIR64: define{{.*}} spir_func i63 @ReturnPassing(
// SPIR: define{{.*}} spir_func i63 @ReturnPassing(
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// HEX: define{{.*}} i63 @ReturnPassing(
// LANAI: define{{.*}} i63 @ReturnPassing(
// R600: define{{.*}} i63 @ReturnPassing(
// ARC: define{{.*}} i63 @ReturnPassing(
// XCORE: define{{.*}} i63 @ReturnPassing(
// RISCV64: define{{.*}} signext i63 @ReturnPassing(
// RISCV32: define{{.*}} i63 @ReturnPassing(
// WASM: define{{.*}} i63 @ReturnPassing(
// SYSTEMZ: define{{.*}} signext i63 @ReturnPassing(
// PPC64: define{{.*}} signext i63 @ReturnPassing(
// PPC32: define{{.*}} i63 @ReturnPassing(
// AARCH64: define{{.*}} i63 @ReturnPassing(
// AARCH64DARWIN: define{{.*}} i63 @ReturnPassing(
// ARM: define{{.*}} arm_aapcscc i63 @ReturnPassing(
[Clang][LoongArch] Implement ABI lowering Reuse most of RISCV's implementation with several exceptions: 1. Assign signext/zeroext attribute to args passed in stack. On RISCV, integer scalars passed in registers have signext/zeroext when promoted, but are anyext if passed on the stack. This is defined in early RISCV ABI specification. But after this change [1], integers should also be signext/zeroext if passed on the stack. So I think RISCV's ABI lowering should be updated [2]. While in LoongArch ABI spec, we can see that integer scalars narrower than GRLEN bits are zero/sign-extended no matter passed in registers or on the stack. 2. Zero-width bit fields are ignored. This matches GCC's behavior but it hasn't been documented in ABI sepc. See https://gcc.gnu.org/r12-8294. 3. `char` is signed by default. There is another difference worth mentioning is that `char` is signed by default on LoongArch while it is unsigned on RISCV. This patch also adds `_BitInt` type support to LoongArch and handle it in LoongArchABIInfo::classifyArgumentType. [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/cec39a064ee0e5b0129973fffab7e3ad1710498f [2] https://github.com/llvm/llvm-project/issues/57261 Differential Revision: https://reviews.llvm.org/D132285
2022-09-19 10:23:21 +08:00
// LA64: define{{.*}} signext i63 @ReturnPassing(
// LA32: define{{.*}} i63 @ReturnPassing(
Implement _ExtInt ABI for all ABIs in Clang, enable type for ABIs This is the result of an audit of all of the ABIs in clang to implement and enable the type for those targets. Additionally, this finds an issue with integer-promotion passing for a few platforms when using _ExtInt of < int, so this also corrects that resulting in signext/zeroext being on a params of those types in some platforms. Differential Revisions: https://reviews.llvm.org/D79118
2020-04-29 12:48:07 -07:00
[Clang] [NFC] Fix unintended `-Wreturn-type` warnings everywhere in the test suite (#123464) In preparation of making `-Wreturn-type` default to an error (as there is virtually no situation where you’d *want* to fall off the end of a function that is supposed to return a value), this patch fixes tests that have relied on this being only a warning, of which there seem to be 3 kinds: 1. Tests which for no apparent reason have a function that triggers the warning. I suspect that a lot of these were on accident (or from before the warning was introduced), since a lot of people will open issues w/ their problematic code in the `main` function (which is the one case where you don’t need to return from a non-void function, after all...), which someone will then copy, possibly into a namespace, possibly renaming it, the end result of that being that you end up w/ something that definitely is not `main` anymore, but which still is declared as returning `int`, and which still has no return statement (another reason why I think this might apply to a lot of these is because usually the actual return type of such problematic functions is quite literally `int`). A lot of these are really old tests that don’t use `-verify`, which is why no-one noticed or had to care about the extra warning that was already being emitted by them until now. 2. Tests which test either `-Wreturn-type`, `[[noreturn]]`, or what codegen and sanitisers do whenever you do fall off the end of a function. 3. Tests where I struggle to figure out what is even being tested (usually because they’re Objective-C tests, and I don’t know Objective-C), whether falling off the end of a function matters in the first place, and tests where actually spelling out an expression to return would be rather cumbersome (e.g. matrix types currently don’t support list initialisation, so I can’t write e.g. `return {}`). For tests that fall into categories 2 and 3, I just added `-Wno-error=return-type` to the `RUN` lines and called it a day. This was especially necessary for the former since `-Wreturn-type` is an analysis-based warning, meaning that it is currently impossible to test for more than one occurrence of it in the same compilation if it defaults to an error since the analysis pass is skipped for subsequent functions as soon as an error is emitted. I’ve also added `-Werror=return-type` to a few tests that I had already updated as this patch was previously already making the warning an error by default, but we’ve decided to split that into two patches instead.
2025-01-18 19:16:33 +01:00
_BitInt(64) ReturnPassing2(void) { return 0; }
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// LIN64: define{{.*}} i64 @ReturnPassing2(
[NFC] Split ext-int calling convention tests into their own file. I'm currently auditing all of the calling convention implications of _ExtInt for all platforms, so splitting them up into their own test will make this a much easier task to organize.
2020-04-29 12:18:59 -07:00
// WIN64: define dso_local i64 @ReturnPassing2(
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// LIN32: define{{.*}} i64 @ReturnPassing2(
[NFC] Split ext-int calling convention tests into their own file. I'm currently auditing all of the calling convention implications of _ExtInt for all platforms, so splitting them up into their own test will make this a much easier task to organize.
2020-04-29 12:18:59 -07:00
// WIN32: define dso_local i64 @ReturnPassing2(
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// NACL: define{{.*}} i64 @ReturnPassing2(
// NVPTX64: define{{.*}} i64 @ReturnPassing2(
// NVPTX: define{{.*}} i64 @ReturnPassing2(
// SPARCV9: define{{.*}} i64 @ReturnPassing2(
// SPARC: define{{.*}} i64 @ReturnPassing2(
// MIPS64: define{{.*}} i64 @ReturnPassing2(
// MIPS: define{{.*}} i64 @ReturnPassing2(
[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
// SPIR64: define{{.*}} spir_func i64 @ReturnPassing2(
// SPIR: define{{.*}} spir_func i64 @ReturnPassing2(
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// HEX: define{{.*}} i64 @ReturnPassing2(
// LANAI: define{{.*}} i64 @ReturnPassing2(
// R600: define{{.*}} i64 @ReturnPassing2(
// ARC: define{{.*}} i64 @ReturnPassing2(
// XCORE: define{{.*}} i64 @ReturnPassing2(
// RISCV64: define{{.*}} i64 @ReturnPassing2(
// RISCV32: define{{.*}} i64 @ReturnPassing2(
// WASM: define{{.*}} i64 @ReturnPassing2(
// SYSTEMZ: define{{.*}} i64 @ReturnPassing2(
// PPC64: define{{.*}} i64 @ReturnPassing2(
// PPC32: define{{.*}} i64 @ReturnPassing2(
// AARCH64: define{{.*}} i64 @ReturnPassing2(
// AARCH64DARWIN: define{{.*}} i64 @ReturnPassing2(
// ARM: define{{.*}} arm_aapcscc i64 @ReturnPassing2(
[Clang][LoongArch] Implement ABI lowering Reuse most of RISCV's implementation with several exceptions: 1. Assign signext/zeroext attribute to args passed in stack. On RISCV, integer scalars passed in registers have signext/zeroext when promoted, but are anyext if passed on the stack. This is defined in early RISCV ABI specification. But after this change [1], integers should also be signext/zeroext if passed on the stack. So I think RISCV's ABI lowering should be updated [2]. While in LoongArch ABI spec, we can see that integer scalars narrower than GRLEN bits are zero/sign-extended no matter passed in registers or on the stack. 2. Zero-width bit fields are ignored. This matches GCC's behavior but it hasn't been documented in ABI sepc. See https://gcc.gnu.org/r12-8294. 3. `char` is signed by default. There is another difference worth mentioning is that `char` is signed by default on LoongArch while it is unsigned on RISCV. This patch also adds `_BitInt` type support to LoongArch and handle it in LoongArchABIInfo::classifyArgumentType. [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/cec39a064ee0e5b0129973fffab7e3ad1710498f [2] https://github.com/llvm/llvm-project/issues/57261 Differential Revision: https://reviews.llvm.org/D132285
2022-09-19 10:23:21 +08:00
// LA64: define{{.*}} i64 @ReturnPassing2(
// LA32: define{{.*}} i64 @ReturnPassing2(
Implement _ExtInt ABI for all ABIs in Clang, enable type for ABIs This is the result of an audit of all of the ABIs in clang to implement and enable the type for those targets. Additionally, this finds an issue with integer-promotion passing for a few platforms when using _ExtInt of < int, so this also corrects that resulting in signext/zeroext being on a params of those types in some platforms. Differential Revisions: https://reviews.llvm.org/D79118
2020-04-29 12:48:07 -07:00
[Clang] [NFC] Fix unintended `-Wreturn-type` warnings everywhere in the test suite (#123464) In preparation of making `-Wreturn-type` default to an error (as there is virtually no situation where you’d *want* to fall off the end of a function that is supposed to return a value), this patch fixes tests that have relied on this being only a warning, of which there seem to be 3 kinds: 1. Tests which for no apparent reason have a function that triggers the warning. I suspect that a lot of these were on accident (or from before the warning was introduced), since a lot of people will open issues w/ their problematic code in the `main` function (which is the one case where you don’t need to return from a non-void function, after all...), which someone will then copy, possibly into a namespace, possibly renaming it, the end result of that being that you end up w/ something that definitely is not `main` anymore, but which still is declared as returning `int`, and which still has no return statement (another reason why I think this might apply to a lot of these is because usually the actual return type of such problematic functions is quite literally `int`). A lot of these are really old tests that don’t use `-verify`, which is why no-one noticed or had to care about the extra warning that was already being emitted by them until now. 2. Tests which test either `-Wreturn-type`, `[[noreturn]]`, or what codegen and sanitisers do whenever you do fall off the end of a function. 3. Tests where I struggle to figure out what is even being tested (usually because they’re Objective-C tests, and I don’t know Objective-C), whether falling off the end of a function matters in the first place, and tests where actually spelling out an expression to return would be rather cumbersome (e.g. matrix types currently don’t support list initialisation, so I can’t write e.g. `return {}`). For tests that fall into categories 2 and 3, I just added `-Wno-error=return-type` to the `RUN` lines and called it a day. This was especially necessary for the former since `-Wreturn-type` is an analysis-based warning, meaning that it is currently impossible to test for more than one occurrence of it in the same compilation if it defaults to an error since the analysis pass is skipped for subsequent functions as soon as an error is emitted. I’ve also added `-Werror=return-type` to a few tests that I had already updated as this patch was previously already making the warning an error by default, but we’ve decided to split that into two patches instead.
2025-01-18 19:16:33 +01:00
_BitInt(127) ReturnPassing3(void) { return 0; }
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// LIN64: define{{.*}} { i64, i64 } @ReturnPassing3(
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// WIN64: define dso_local void @ReturnPassing3(ptr dead_on_unwind noalias writable sret
// LIN32: define{{.*}} void @ReturnPassing3(ptr dead_on_unwind noalias writable sret
// WIN32: define dso_local void @ReturnPassing3(ptr dead_on_unwind noalias writable sret
// NACL: define{{.*}} void @ReturnPassing3(ptr dead_on_unwind noalias writable sret
Implement _ExtInt ABI for all ABIs in Clang, enable type for ABIs This is the result of an audit of all of the ABIs in clang to implement and enable the type for those targets. Additionally, this finds an issue with integer-promotion passing for a few platforms when using _ExtInt of < int, so this also corrects that resulting in signext/zeroext being on a params of those types in some platforms. Differential Revisions: https://reviews.llvm.org/D79118
2020-04-29 12:48:07 -07:00
// NVPTX/64 makes the intentional choice to put all return values direct, even
// large structures, so we do the same here.
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// NVPTX64: define{{.*}} i127 @ReturnPassing3(
// NVPTX: define{{.*}} i127 @ReturnPassing3(
// SPARCV9: define{{.*}} i127 @ReturnPassing3(
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// SPARC: define{{.*}} void @ReturnPassing3(ptr dead_on_unwind noalias writable sret
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// MIPS64: define{{.*}} i127 @ReturnPassing3(
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// MIPS: define{{.*}} void @ReturnPassing3(ptr dead_on_unwind noalias writable sret
// SPIR64: define{{.*}} spir_func void @ReturnPassing3(ptr dead_on_unwind noalias writable sret
// SPIR: define{{.*}} spir_func void @ReturnPassing3(ptr dead_on_unwind noalias writable sret
// HEX: define{{.*}} void @ReturnPassing3(ptr dead_on_unwind noalias writable sret
// LANAI: define{{.*}} void @ReturnPassing3(ptr dead_on_unwind noalias writable sret
// R600: define{{.*}} void @ReturnPassing3(ptr addrspace(5) dead_on_unwind noalias writable sret
// ARC: define{{.*}} void @ReturnPassing3(ptr dead_on_unwind noalias writable sret
// XCORE: define{{.*}} void @ReturnPassing3(ptr dead_on_unwind noalias writable sret
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// RISCV64: define{{.*}} i127 @ReturnPassing3(
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// RISCV32: define{{.*}} void @ReturnPassing3(ptr dead_on_unwind noalias writable sret
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// WASM: define{{.*}} i127 @ReturnPassing3(
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// SYSTEMZ: define{{.*}} void @ReturnPassing3(ptr dead_on_unwind noalias writable sret
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// PPC64: define{{.*}} i127 @ReturnPassing3(
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// PPC32: define{{.*}} void @ReturnPassing3(ptr dead_on_unwind noalias writable sret
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// AARCH64: define{{.*}} i127 @ReturnPassing3(
// AARCH64DARWIN: define{{.*}} i127 @ReturnPassing3(
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// ARM: define{{.*}} arm_aapcscc void @ReturnPassing3(ptr dead_on_unwind noalias writable sret
[Clang][LoongArch] Implement ABI lowering Reuse most of RISCV's implementation with several exceptions: 1. Assign signext/zeroext attribute to args passed in stack. On RISCV, integer scalars passed in registers have signext/zeroext when promoted, but are anyext if passed on the stack. This is defined in early RISCV ABI specification. But after this change [1], integers should also be signext/zeroext if passed on the stack. So I think RISCV's ABI lowering should be updated [2]. While in LoongArch ABI spec, we can see that integer scalars narrower than GRLEN bits are zero/sign-extended no matter passed in registers or on the stack. 2. Zero-width bit fields are ignored. This matches GCC's behavior but it hasn't been documented in ABI sepc. See https://gcc.gnu.org/r12-8294. 3. `char` is signed by default. There is another difference worth mentioning is that `char` is signed by default on LoongArch while it is unsigned on RISCV. This patch also adds `_BitInt` type support to LoongArch and handle it in LoongArchABIInfo::classifyArgumentType. [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/cec39a064ee0e5b0129973fffab7e3ad1710498f [2] https://github.com/llvm/llvm-project/issues/57261 Differential Revision: https://reviews.llvm.org/D132285
2022-09-19 10:23:21 +08:00
// LA64: define{{.*}} i127 @ReturnPassing3(
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// LA32: define{{.*}} void @ReturnPassing3(ptr dead_on_unwind noalias writable sret
Implement _ExtInt ABI for all ABIs in Clang, enable type for ABIs This is the result of an audit of all of the ABIs in clang to implement and enable the type for those targets. Additionally, this finds an issue with integer-promotion passing for a few platforms when using _ExtInt of < int, so this also corrects that resulting in signext/zeroext being on a params of those types in some platforms. Differential Revisions: https://reviews.llvm.org/D79118
2020-04-29 12:48:07 -07:00
[Clang] [NFC] Fix unintended `-Wreturn-type` warnings everywhere in the test suite (#123464) In preparation of making `-Wreturn-type` default to an error (as there is virtually no situation where you’d *want* to fall off the end of a function that is supposed to return a value), this patch fixes tests that have relied on this being only a warning, of which there seem to be 3 kinds: 1. Tests which for no apparent reason have a function that triggers the warning. I suspect that a lot of these were on accident (or from before the warning was introduced), since a lot of people will open issues w/ their problematic code in the `main` function (which is the one case where you don’t need to return from a non-void function, after all...), which someone will then copy, possibly into a namespace, possibly renaming it, the end result of that being that you end up w/ something that definitely is not `main` anymore, but which still is declared as returning `int`, and which still has no return statement (another reason why I think this might apply to a lot of these is because usually the actual return type of such problematic functions is quite literally `int`). A lot of these are really old tests that don’t use `-verify`, which is why no-one noticed or had to care about the extra warning that was already being emitted by them until now. 2. Tests which test either `-Wreturn-type`, `[[noreturn]]`, or what codegen and sanitisers do whenever you do fall off the end of a function. 3. Tests where I struggle to figure out what is even being tested (usually because they’re Objective-C tests, and I don’t know Objective-C), whether falling off the end of a function matters in the first place, and tests where actually spelling out an expression to return would be rather cumbersome (e.g. matrix types currently don’t support list initialisation, so I can’t write e.g. `return {}`). For tests that fall into categories 2 and 3, I just added `-Wno-error=return-type` to the `RUN` lines and called it a day. This was especially necessary for the former since `-Wreturn-type` is an analysis-based warning, meaning that it is currently impossible to test for more than one occurrence of it in the same compilation if it defaults to an error since the analysis pass is skipped for subsequent functions as soon as an error is emitted. I’ve also added `-Werror=return-type` to a few tests that I had already updated as this patch was previously already making the warning an error by default, but we’ve decided to split that into two patches instead.
2025-01-18 19:16:33 +01:00
_BitInt(128) ReturnPassing4(void) { return 0; }
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// LIN64: define{{.*}} { i64, i64 } @ReturnPassing4(
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// WIN64: define dso_local void @ReturnPassing4(ptr dead_on_unwind noalias writable sret
// LIN32: define{{.*}} void @ReturnPassing4(ptr dead_on_unwind noalias writable sret
// WIN32: define dso_local void @ReturnPassing4(ptr dead_on_unwind noalias writable sret
// NACL: define{{.*}} void @ReturnPassing4(ptr dead_on_unwind noalias writable sret
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// NVPTX64: define{{.*}} i128 @ReturnPassing4(
// NVPTX: define{{.*}} i128 @ReturnPassing4(
// SPARCV9: define{{.*}} i128 @ReturnPassing4(
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// SPARC: define{{.*}} void @ReturnPassing4(ptr dead_on_unwind noalias writable sret
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// MIPS64: define{{.*}} i128 @ReturnPassing4(
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// MIPS: define{{.*}} void @ReturnPassing4(ptr dead_on_unwind noalias writable sret
// SPIR64: define{{.*}} spir_func void @ReturnPassing4(ptr dead_on_unwind noalias writable sret
// SPIR: define{{.*}} spir_func void @ReturnPassing4(ptr dead_on_unwind noalias writable sret
// HEX: define{{.*}} void @ReturnPassing4(ptr dead_on_unwind noalias writable sret
// LANAI: define{{.*}} void @ReturnPassing4(ptr dead_on_unwind noalias writable sret
// R600: define{{.*}} void @ReturnPassing4(ptr addrspace(5) dead_on_unwind noalias writable sret
// ARC: define{{.*}} void @ReturnPassing4(ptr dead_on_unwind noalias writable sret
// XCORE: define{{.*}} void @ReturnPassing4(ptr dead_on_unwind noalias writable sret
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// RISCV64: define{{.*}} i128 @ReturnPassing4(
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// RISCV32: define{{.*}} void @ReturnPassing4(ptr dead_on_unwind noalias writable sret
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// WASM: define{{.*}} i128 @ReturnPassing4(
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// SYSTEMZ: define{{.*}} void @ReturnPassing4(ptr dead_on_unwind noalias writable sret
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// PPC64: define{{.*}} i128 @ReturnPassing4(
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// PPC32: define{{.*}} void @ReturnPassing4(ptr dead_on_unwind noalias writable sret
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-30 20:45:56 -08:00
// AARCH64: define{{.*}} i128 @ReturnPassing4(
// AARCH64DARWIN: define{{.*}} i128 @ReturnPassing4(
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// ARM: define{{.*}} arm_aapcscc void @ReturnPassing4(ptr dead_on_unwind noalias writable sret
[Clang][LoongArch] Implement ABI lowering Reuse most of RISCV's implementation with several exceptions: 1. Assign signext/zeroext attribute to args passed in stack. On RISCV, integer scalars passed in registers have signext/zeroext when promoted, but are anyext if passed on the stack. This is defined in early RISCV ABI specification. But after this change [1], integers should also be signext/zeroext if passed on the stack. So I think RISCV's ABI lowering should be updated [2]. While in LoongArch ABI spec, we can see that integer scalars narrower than GRLEN bits are zero/sign-extended no matter passed in registers or on the stack. 2. Zero-width bit fields are ignored. This matches GCC's behavior but it hasn't been documented in ABI sepc. See https://gcc.gnu.org/r12-8294. 3. `char` is signed by default. There is another difference worth mentioning is that `char` is signed by default on LoongArch while it is unsigned on RISCV. This patch also adds `_BitInt` type support to LoongArch and handle it in LoongArchABIInfo::classifyArgumentType. [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/cec39a064ee0e5b0129973fffab7e3ad1710498f [2] https://github.com/llvm/llvm-project/issues/57261 Differential Revision: https://reviews.llvm.org/D132285
2022-09-19 10:23:21 +08:00
// LA64: define{{.*}} i128 @ReturnPassing4(
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// LA32: define{{.*}} void @ReturnPassing4(ptr dead_on_unwind noalias writable sret
Implement _ExtInt ABI for all ABIs in Clang, enable type for ABIs This is the result of an audit of all of the ABIs in clang to implement and enable the type for those targets. Additionally, this finds an issue with integer-promotion passing for a few platforms when using _ExtInt of < int, so this also corrects that resulting in signext/zeroext being on a params of those types in some platforms. Differential Revisions: https://reviews.llvm.org/D79118
2020-04-29 12:48:07 -07:00
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
#if __BITINT_MAXWIDTH__ > 128
[Clang] [NFC] Fix unintended `-Wreturn-type` warnings everywhere in the test suite (#123464) In preparation of making `-Wreturn-type` default to an error (as there is virtually no situation where you’d *want* to fall off the end of a function that is supposed to return a value), this patch fixes tests that have relied on this being only a warning, of which there seem to be 3 kinds: 1. Tests which for no apparent reason have a function that triggers the warning. I suspect that a lot of these were on accident (or from before the warning was introduced), since a lot of people will open issues w/ their problematic code in the `main` function (which is the one case where you don’t need to return from a non-void function, after all...), which someone will then copy, possibly into a namespace, possibly renaming it, the end result of that being that you end up w/ something that definitely is not `main` anymore, but which still is declared as returning `int`, and which still has no return statement (another reason why I think this might apply to a lot of these is because usually the actual return type of such problematic functions is quite literally `int`). A lot of these are really old tests that don’t use `-verify`, which is why no-one noticed or had to care about the extra warning that was already being emitted by them until now. 2. Tests which test either `-Wreturn-type`, `[[noreturn]]`, or what codegen and sanitisers do whenever you do fall off the end of a function. 3. Tests where I struggle to figure out what is even being tested (usually because they’re Objective-C tests, and I don’t know Objective-C), whether falling off the end of a function matters in the first place, and tests where actually spelling out an expression to return would be rather cumbersome (e.g. matrix types currently don’t support list initialisation, so I can’t write e.g. `return {}`). For tests that fall into categories 2 and 3, I just added `-Wno-error=return-type` to the `RUN` lines and called it a day. This was especially necessary for the former since `-Wreturn-type` is an analysis-based warning, meaning that it is currently impossible to test for more than one occurrence of it in the same compilation if it defaults to an error since the analysis pass is skipped for subsequent functions as soon as an error is emitted. I’ve also added `-Werror=return-type` to a few tests that I had already updated as this patch was previously already making the warning an error by default, but we’ve decided to split that into two patches instead.
2025-01-18 19:16:33 +01:00
_BitInt(129) ReturnPassing5(void) { return 0; }
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// LIN64: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// WIN64: define dso_local void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// LIN32: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// WIN32: define dso_local void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
[Clang] Fix incorrect passing of _BitInt args (#90741) This patch removes incorrect `byval` attribute from pointer argument passed with >128 bit long _BitInt types.
2024-05-15 10:51:32 +01:00
// AARCH64: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// NACL-NOT: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
// NVPTX64-NOT: define{{.*}} i129 @ReturnPassing5(
// NVPTX-NOT: define{{.*}} i129 @ReturnPassing5(
// SPARCV9-NOT: define{{.*}} i129 @ReturnPassing5(
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// SPARC-NOT: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// MIPS64-NOT: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// MIPS-NOT: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// SPIR64-NOT: define{{.*}} spir_func void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// SPIR-NOT: define{{.*}} spir_func void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// HEX-NOT: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// LANAI-NOT: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
[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
// R600-NOT: define{{.*}} void @ReturnPassing5(ptr addrspace(5) noalias sret
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// ARC-NOT: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind inreg noalias writable sret
// XCORE-NOT: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// RISCV64-NOT: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// RISCV32-NOT: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// WASM-NOT: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// SYSTEMZ-NOT: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// PPC64-NOT: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// PPC32-NOT: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// AARCH64DARWIN-NOT: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// ARM-NOT: define{{.*}} arm_aapcscc void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// LA64-NOT: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
// LA32-NOT: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias writable sret
Implement _ExtInt ABI for all ABIs in Clang, enable type for ABIs This is the result of an audit of all of the ABIs in clang to implement and enable the type for those targets. Additionally, this finds an issue with integer-promotion passing for a few platforms when using _ExtInt of < int, so this also corrects that resulting in signext/zeroext being on a params of those types in some platforms. Differential Revisions: https://reviews.llvm.org/D79118
2020-04-29 12:48:07 -07:00
// SparcV9 is odd in that it has a return-size limit of 256, not 128 or 64
// like other platforms, so test to make sure this behavior will still work.
[Clang] [NFC] Fix unintended `-Wreturn-type` warnings everywhere in the test suite (#123464) In preparation of making `-Wreturn-type` default to an error (as there is virtually no situation where you’d *want* to fall off the end of a function that is supposed to return a value), this patch fixes tests that have relied on this being only a warning, of which there seem to be 3 kinds: 1. Tests which for no apparent reason have a function that triggers the warning. I suspect that a lot of these were on accident (or from before the warning was introduced), since a lot of people will open issues w/ their problematic code in the `main` function (which is the one case where you don’t need to return from a non-void function, after all...), which someone will then copy, possibly into a namespace, possibly renaming it, the end result of that being that you end up w/ something that definitely is not `main` anymore, but which still is declared as returning `int`, and which still has no return statement (another reason why I think this might apply to a lot of these is because usually the actual return type of such problematic functions is quite literally `int`). A lot of these are really old tests that don’t use `-verify`, which is why no-one noticed or had to care about the extra warning that was already being emitted by them until now. 2. Tests which test either `-Wreturn-type`, `[[noreturn]]`, or what codegen and sanitisers do whenever you do fall off the end of a function. 3. Tests where I struggle to figure out what is even being tested (usually because they’re Objective-C tests, and I don’t know Objective-C), whether falling off the end of a function matters in the first place, and tests where actually spelling out an expression to return would be rather cumbersome (e.g. matrix types currently don’t support list initialisation, so I can’t write e.g. `return {}`). For tests that fall into categories 2 and 3, I just added `-Wno-error=return-type` to the `RUN` lines and called it a day. This was especially necessary for the former since `-Wreturn-type` is an analysis-based warning, meaning that it is currently impossible to test for more than one occurrence of it in the same compilation if it defaults to an error since the analysis pass is skipped for subsequent functions as soon as an error is emitted. I’ve also added `-Werror=return-type` to a few tests that I had already updated as this patch was previously already making the warning an error by default, but we’ve decided to split that into two patches instead.
2025-01-18 19:16:33 +01:00
_BitInt(256) ReturnPassing6(void) { return 0; }
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
// SPARCV9-NOT: define{{.*}} i256 @ReturnPassing6(
[Clang] [NFC] Fix unintended `-Wreturn-type` warnings everywhere in the test suite (#123464) In preparation of making `-Wreturn-type` default to an error (as there is virtually no situation where you’d *want* to fall off the end of a function that is supposed to return a value), this patch fixes tests that have relied on this being only a warning, of which there seem to be 3 kinds: 1. Tests which for no apparent reason have a function that triggers the warning. I suspect that a lot of these were on accident (or from before the warning was introduced), since a lot of people will open issues w/ their problematic code in the `main` function (which is the one case where you don’t need to return from a non-void function, after all...), which someone will then copy, possibly into a namespace, possibly renaming it, the end result of that being that you end up w/ something that definitely is not `main` anymore, but which still is declared as returning `int`, and which still has no return statement (another reason why I think this might apply to a lot of these is because usually the actual return type of such problematic functions is quite literally `int`). A lot of these are really old tests that don’t use `-verify`, which is why no-one noticed or had to care about the extra warning that was already being emitted by them until now. 2. Tests which test either `-Wreturn-type`, `[[noreturn]]`, or what codegen and sanitisers do whenever you do fall off the end of a function. 3. Tests where I struggle to figure out what is even being tested (usually because they’re Objective-C tests, and I don’t know Objective-C), whether falling off the end of a function matters in the first place, and tests where actually spelling out an expression to return would be rather cumbersome (e.g. matrix types currently don’t support list initialisation, so I can’t write e.g. `return {}`). For tests that fall into categories 2 and 3, I just added `-Wno-error=return-type` to the `RUN` lines and called it a day. This was especially necessary for the former since `-Wreturn-type` is an analysis-based warning, meaning that it is currently impossible to test for more than one occurrence of it in the same compilation if it defaults to an error since the analysis pass is skipped for subsequent functions as soon as an error is emitted. I’ve also added `-Werror=return-type` to a few tests that I had already updated as this patch was previously already making the warning an error by default, but we’ve decided to split that into two patches instead.
2025-01-18 19:16:33 +01:00
_BitInt(257) ReturnPassing7(void) { return 0; }
[Clang] Set writable and dead_on_unwind attributes on sret arguments (#77116) Set the writable and dead_on_unwind attributes for sret arguments. These indicate that the argument points to writable memory (and it's legal to introduce spurious writes to it on entry to the function) and that the argument memory will not be used if the call unwinds. This enables additional MemCpyOpt/DSE/LICM optimizations.
2024-01-11 09:46:54 +01:00
// SPARCV9-NOT: define{{.*}} void @ReturnPassing7(ptr dead_on_unwind noalias writable sret
Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of 86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This hopefully fixes them.
2022-01-29 08:11:14 -05:00
#endif
Reference in New Issue Copy Permalink