maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGen/arm-aapcs-vfp.c

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

150 lines
7.1 KiB
C
Raw Normal View History

Tests: check for target availability for target-specific tests. Lots of tests are using an explicit target triple w/o first checking that the target is actually available. Add a REQUIRES clause to a bunch of them. This should hopefully unbreak bots which don't configure w/ all targets enabled. llvm-svn: 159949
2012-07-10 02:34:21 +08:00
// REQUIRES: arm-registered-target
This test also requires an aarch64 target. llvm-svn: 222268
2014-11-19 06:36:11 +08:00
// REQUIRES: aarch64-registered-target
Handle "homogeneous aggregates" as required by the ARM AAPCS-VFP ABI. A homogeneous aggregate is an aggregate data structure where after flattening any nesting there are 1 to 4 elements of the same base type that is either a float, double, or Neon vector. All Neon vectors of the same size, either 64 or 128 bits, are treated as equivalent for this purpose. When using the AAPCS-VFP ABI, check for homogeneous aggregates and pass them as arguments by expanding them into a sequence of their base types. This requires extending the existing support for expanded arguments to handle not only structs, but also constant arrays and complex types. llvm-svn: 136767
2011-08-03 13:58:22 +08:00
// RUN: %clang_cc1 -triple thumbv7-apple-darwin9 \
// RUN: -target-abi aapcs \
// RUN: -target-cpu cortex-a8 \
// RUN: -mfloat-abi hard \
// RUN: -ffreestanding \
// RUN: -emit-llvm -w -o - %s | FileCheck %s
Properly factor Native Client defines to support NaCl as an OS with x86/ARM architecture llvm-svn: 165722
2012-10-12 00:55:58 +08:00
// RUN: %clang_cc1 -triple armv7-unknown-nacl-gnueabi \
// RUN: -target-cpu cortex-a8 \
// RUN: -mfloat-abi hard \
// RUN: -ffreestanding \
// RUN: -emit-llvm -w -o - %s | FileCheck %s
[ARM64] Allow the disabling of NEON and crypto instructions. Update tests to pass -target-feature +neon. llvm-svn: 206394
2014-04-16 23:33:48 +08:00
// RUN: %clang_cc1 -triple arm64-apple-darwin9 -target-feature +neon \
ARM64: initial clang support commit. This adds Clang support for the ARM64 backend. There are definitely still some rough edges, so please bring up any issues you see with this patch. As with the LLVM commit though, we think it'll be more useful for merging with AArch64 from within the tree. llvm-svn: 205100
2014-03-29 23:09:45 +08:00
// RUN: -ffreestanding \
// RUN: -emit-llvm -w -o - %s | FileCheck -check-prefix=CHECK64 %s
#include <arm_neon.h>
Handle "homogeneous aggregates" as required by the ARM AAPCS-VFP ABI. A homogeneous aggregate is an aggregate data structure where after flattening any nesting there are 1 to 4 elements of the same base type that is either a float, double, or Neon vector. All Neon vectors of the same size, either 64 or 128 bits, are treated as equivalent for this purpose. When using the AAPCS-VFP ABI, check for homogeneous aggregates and pass them as arguments by expanding them into a sequence of their base types. This requires extending the existing support for expanded arguments to handle not only structs, but also constant arrays and complex types. llvm-svn: 136767
2011-08-03 13:58:22 +08:00
struct homogeneous_struct {
float f[2];
float f3;
float f4;
};
Reapply r208417 (olista01 'ARM: HFAs must be passed in consecutive registers'). Bots are now pacified. llvm-svn: 208425
2014-05-10 00:21:39 +08:00
// CHECK: define arm_aapcs_vfpcc %struct.homogeneous_struct @test_struct(%struct.homogeneous_struct %{{.*}})
AArch64: simplify PCS mapping. Now that LLVM can count the registers needed to implement AAPCS rules, we don't need to duplicate that logic here. This means we can drop the explicit padding and also use more natural types in many cases (e.g. "struct { float arr[3]; }" used to end up as "[2 x double]" to avoid holes on the stack. The one wrinkle is that AAPCS va_arg was also using the register counting machinery. But the local replacement isn't too bad. llvm-svn: 222904
2014-11-28 05:02:49 +08:00
// CHECK64: define %struct.homogeneous_struct @test_struct([4 x float] %{{.*}})
Check for homogeneous aggregate return values with ARM's AAPCS-VFP ABI. llvm-svn: 143530
2011-11-02 12:51:36 +08:00
extern struct homogeneous_struct struct_callee(struct homogeneous_struct);
struct homogeneous_struct test_struct(struct homogeneous_struct arg) {
return struct_callee(arg);
Handle "homogeneous aggregates" as required by the ARM AAPCS-VFP ABI. A homogeneous aggregate is an aggregate data structure where after flattening any nesting there are 1 to 4 elements of the same base type that is either a float, double, or Neon vector. All Neon vectors of the same size, either 64 or 128 bits, are treated as equivalent for this purpose. When using the AAPCS-VFP ABI, check for homogeneous aggregates and pass them as arguments by expanding them into a sequence of their base types. This requires extending the existing support for expanded arguments to handle not only structs, but also constant arrays and complex types. llvm-svn: 136767
2011-08-03 13:58:22 +08:00
}
Reapply r208417 (olista01 'ARM: HFAs must be passed in consecutive registers'). Bots are now pacified. llvm-svn: 208425
2014-05-10 00:21:39 +08:00
// CHECK: define arm_aapcs_vfpcc void @test_struct_variadic(%struct.homogeneous_struct* {{.*}}, ...)
[ARM] Fix AAPCS-VFP non-compliance when returning HFA from variadic functions. Arguments and return values must always be marshalled as for the base AAPCS when the callee is a variadic function. Patch by Oliver Stannard! llvm-svn: 200307
2014-01-28 18:56:36 +08:00
struct homogeneous_struct test_struct_variadic(struct homogeneous_struct arg, ...) {
return struct_callee(arg);
}
Handle "homogeneous aggregates" as required by the ARM AAPCS-VFP ABI. A homogeneous aggregate is an aggregate data structure where after flattening any nesting there are 1 to 4 elements of the same base type that is either a float, double, or Neon vector. All Neon vectors of the same size, either 64 or 128 bits, are treated as equivalent for this purpose. When using the AAPCS-VFP ABI, check for homogeneous aggregates and pass them as arguments by expanding them into a sequence of their base types. This requires extending the existing support for expanded arguments to handle not only structs, but also constant arrays and complex types. llvm-svn: 136767
2011-08-03 13:58:22 +08:00
struct nested_array {
double d[4];
};
Reapply r208417 (olista01 'ARM: HFAs must be passed in consecutive registers'). Bots are now pacified. llvm-svn: 208425
2014-05-10 00:21:39 +08:00
// CHECK: define arm_aapcs_vfpcc void @test_array(%struct.nested_array %{{.*}})
AArch64: simplify PCS mapping. Now that LLVM can count the registers needed to implement AAPCS rules, we don't need to duplicate that logic here. This means we can drop the explicit padding and also use more natural types in many cases (e.g. "struct { float arr[3]; }" used to end up as "[2 x double]" to avoid holes on the stack. The one wrinkle is that AAPCS va_arg was also using the register counting machinery. But the local replacement isn't too bad. llvm-svn: 222904
2014-11-28 05:02:49 +08:00
// CHECK64: define void @test_array([4 x double] %{{.*}})
Handle "homogeneous aggregates" as required by the ARM AAPCS-VFP ABI. A homogeneous aggregate is an aggregate data structure where after flattening any nesting there are 1 to 4 elements of the same base type that is either a float, double, or Neon vector. All Neon vectors of the same size, either 64 or 128 bits, are treated as equivalent for this purpose. When using the AAPCS-VFP ABI, check for homogeneous aggregates and pass them as arguments by expanding them into a sequence of their base types. This requires extending the existing support for expanded arguments to handle not only structs, but also constant arrays and complex types. llvm-svn: 136767
2011-08-03 13:58:22 +08:00
extern void array_callee(struct nested_array);
void test_array(struct nested_array arg) {
array_callee(arg);
}
extern void complex_callee(__complex__ double);
Reapply r208417 (olista01 'ARM: HFAs must be passed in consecutive registers'). Bots are now pacified. llvm-svn: 208425
2014-05-10 00:21:39 +08:00
// CHECK: define arm_aapcs_vfpcc void @test_complex({ double, double } %{{.*}})
AArch64: simplify PCS mapping. Now that LLVM can count the registers needed to implement AAPCS rules, we don't need to duplicate that logic here. This means we can drop the explicit padding and also use more natural types in many cases (e.g. "struct { float arr[3]; }" used to end up as "[2 x double]" to avoid holes on the stack. The one wrinkle is that AAPCS va_arg was also using the register counting machinery. But the local replacement isn't too bad. llvm-svn: 222904
2014-11-28 05:02:49 +08:00
// CHECK64: define void @test_complex([2 x double] %cd.coerce)
Handle "homogeneous aggregates" as required by the ARM AAPCS-VFP ABI. A homogeneous aggregate is an aggregate data structure where after flattening any nesting there are 1 to 4 elements of the same base type that is either a float, double, or Neon vector. All Neon vectors of the same size, either 64 or 128 bits, are treated as equivalent for this purpose. When using the AAPCS-VFP ABI, check for homogeneous aggregates and pass them as arguments by expanding them into a sequence of their base types. This requires extending the existing support for expanded arguments to handle not only structs, but also constant arrays and complex types. llvm-svn: 136767
2011-08-03 13:58:22 +08:00
void test_complex(__complex__ double cd) {
complex_callee(cd);
}
Add "long double" to permitted list of ARM complex homogeneous aggregates. Under AAPCS, long double is the same as double, which means it should be allowed as part of a homogeneous aggregate. llvm-svn: 160586
2012-07-21 06:29:29 +08:00
// Long double is the same as double on AAPCS, it should be homogeneous.
extern void complex_long_callee(__complex__ long double);
Reapply r208417 (olista01 'ARM: HFAs must be passed in consecutive registers'). Bots are now pacified. llvm-svn: 208425
2014-05-10 00:21:39 +08:00
// CHECK: define arm_aapcs_vfpcc void @test_complex_long({ double, double } %{{.*}})
Add "long double" to permitted list of ARM complex homogeneous aggregates. Under AAPCS, long double is the same as double, which means it should be allowed as part of a homogeneous aggregate. llvm-svn: 160586
2012-07-21 06:29:29 +08:00
void test_complex_long(__complex__ long double cd) {
complex_callee(cd);
}
Handle "homogeneous aggregates" as required by the ARM AAPCS-VFP ABI. A homogeneous aggregate is an aggregate data structure where after flattening any nesting there are 1 to 4 elements of the same base type that is either a float, double, or Neon vector. All Neon vectors of the same size, either 64 or 128 bits, are treated as equivalent for this purpose. When using the AAPCS-VFP ABI, check for homogeneous aggregates and pass them as arguments by expanding them into a sequence of their base types. This requires extending the existing support for expanded arguments to handle not only structs, but also constant arrays and complex types. llvm-svn: 136767
2011-08-03 13:58:22 +08:00
// Structs with more than 4 elements of the base type are not treated
// as homogeneous aggregates. Test that.
struct big_struct {
float f1;
float f[2];
float f3;
float f4;
};
ARM ABI: simplify decisions on whether args can be expanded. Homogeneous aggregates on AAPCS_VFP ARM need to be passed *without* being flattened (e.g. [2 x float] rather than "float, float") for various weird ABI reasons. However, this isn't the case for anything else; further, we know at the ABIArgInfo::getDirect callsites whether this flattening is allowed. So, we can get more unified ARM code, with a simpler Clang, by just using that knowledge directly. llvm-svn: 221559
2014-11-08 06:30:50 +08:00
// CHECK: define arm_aapcs_vfpcc void @test_big([5 x i32] %{{.*}})
ARM64: initial clang support commit. This adds Clang support for the ARM64 backend. There are definitely still some rough edges, so please bring up any issues you see with this patch. As with the LLVM commit though, we think it'll be more useful for merging with AArch64 from within the tree. llvm-svn: 205100
2014-03-29 23:09:45 +08:00
// CHECK64: define void @test_big(%struct.big_struct* %{{.*}})
// CHECK64: call void @llvm.memcpy
// CHECK64: call void @big_callee(%struct.big_struct*
Handle "homogeneous aggregates" as required by the ARM AAPCS-VFP ABI. A homogeneous aggregate is an aggregate data structure where after flattening any nesting there are 1 to 4 elements of the same base type that is either a float, double, or Neon vector. All Neon vectors of the same size, either 64 or 128 bits, are treated as equivalent for this purpose. When using the AAPCS-VFP ABI, check for homogeneous aggregates and pass them as arguments by expanding them into a sequence of their base types. This requires extending the existing support for expanded arguments to handle not only structs, but also constant arrays and complex types. llvm-svn: 136767
2011-08-03 13:58:22 +08:00
extern void big_callee(struct big_struct);
void test_big(struct big_struct arg) {
big_callee(arg);
}
// Make sure that aggregates with multiple base types are not treated as
// homogeneous aggregates.
struct heterogeneous_struct {
float f1;
int i2;
};
ARM ABI: simplify decisions on whether args can be expanded. Homogeneous aggregates on AAPCS_VFP ARM need to be passed *without* being flattened (e.g. [2 x float] rather than "float, float") for various weird ABI reasons. However, this isn't the case for anything else; further, we know at the ABIArgInfo::getDirect callsites whether this flattening is allowed. So, we can get more unified ARM code, with a simpler Clang, by just using that knowledge directly. llvm-svn: 221559
2014-11-08 06:30:50 +08:00
// CHECK: define arm_aapcs_vfpcc void @test_hetero([2 x i32] %{{.*}})
ARM64: initial clang support commit. This adds Clang support for the ARM64 backend. There are definitely still some rough edges, so please bring up any issues you see with this patch. As with the LLVM commit though, we think it'll be more useful for merging with AArch64 from within the tree. llvm-svn: 205100
2014-03-29 23:09:45 +08:00
// CHECK64: define void @test_hetero(i64 %{{.*}})
Handle "homogeneous aggregates" as required by the ARM AAPCS-VFP ABI. A homogeneous aggregate is an aggregate data structure where after flattening any nesting there are 1 to 4 elements of the same base type that is either a float, double, or Neon vector. All Neon vectors of the same size, either 64 or 128 bits, are treated as equivalent for this purpose. When using the AAPCS-VFP ABI, check for homogeneous aggregates and pass them as arguments by expanding them into a sequence of their base types. This requires extending the existing support for expanded arguments to handle not only structs, but also constant arrays and complex types. llvm-svn: 136767
2011-08-03 13:58:22 +08:00
extern void hetero_callee(struct heterogeneous_struct);
void test_hetero(struct heterogeneous_struct arg) {
hetero_callee(arg);
}
// Neon multi-vector types are homogeneous aggregates.
Reapply r208417 (olista01 'ARM: HFAs must be passed in consecutive registers'). Bots are now pacified. llvm-svn: 208425
2014-05-10 00:21:39 +08:00
// CHECK: define arm_aapcs_vfpcc <16 x i8> @f0(%struct.int8x16x4_t %{{.*}})
AArch64: simplify PCS mapping. Now that LLVM can count the registers needed to implement AAPCS rules, we don't need to duplicate that logic here. This means we can drop the explicit padding and also use more natural types in many cases (e.g. "struct { float arr[3]; }" used to end up as "[2 x double]" to avoid holes on the stack. The one wrinkle is that AAPCS va_arg was also using the register counting machinery. But the local replacement isn't too bad. llvm-svn: 222904
2014-11-28 05:02:49 +08:00
// CHECK64: define <16 x i8> @f0([4 x <16 x i8>] %{{.*}})
Handle "homogeneous aggregates" as required by the ARM AAPCS-VFP ABI. A homogeneous aggregate is an aggregate data structure where after flattening any nesting there are 1 to 4 elements of the same base type that is either a float, double, or Neon vector. All Neon vectors of the same size, either 64 or 128 bits, are treated as equivalent for this purpose. When using the AAPCS-VFP ABI, check for homogeneous aggregates and pass them as arguments by expanding them into a sequence of their base types. This requires extending the existing support for expanded arguments to handle not only structs, but also constant arrays and complex types. llvm-svn: 136767
2011-08-03 13:58:22 +08:00
int8x16_t f0(int8x16x4_t v4) {
return vaddq_s8(v4.val[0], v4.val[3]);
}
// ...and it doesn't matter whether the vectors are exactly the same, as long
// as they have the same size.
struct neon_struct {
int8x8x2_t v12;
int32x2_t v3;
int16x4_t v4;
};
Reapply r208417 (olista01 'ARM: HFAs must be passed in consecutive registers'). Bots are now pacified. llvm-svn: 208425
2014-05-10 00:21:39 +08:00
// CHECK: define arm_aapcs_vfpcc void @test_neon(%struct.neon_struct %{{.*}})
AArch64: simplify PCS mapping. Now that LLVM can count the registers needed to implement AAPCS rules, we don't need to duplicate that logic here. This means we can drop the explicit padding and also use more natural types in many cases (e.g. "struct { float arr[3]; }" used to end up as "[2 x double]" to avoid holes on the stack. The one wrinkle is that AAPCS va_arg was also using the register counting machinery. But the local replacement isn't too bad. llvm-svn: 222904
2014-11-28 05:02:49 +08:00
// CHECK64: define void @test_neon([4 x <8 x i8>] %{{.*}})
Handle "homogeneous aggregates" as required by the ARM AAPCS-VFP ABI. A homogeneous aggregate is an aggregate data structure where after flattening any nesting there are 1 to 4 elements of the same base type that is either a float, double, or Neon vector. All Neon vectors of the same size, either 64 or 128 bits, are treated as equivalent for this purpose. When using the AAPCS-VFP ABI, check for homogeneous aggregates and pass them as arguments by expanding them into a sequence of their base types. This requires extending the existing support for expanded arguments to handle not only structs, but also constant arrays and complex types. llvm-svn: 136767
2011-08-03 13:58:22 +08:00
extern void neon_callee(struct neon_struct);
void test_neon(struct neon_struct arg) {
neon_callee(arg);
}
ARM: enable struct byval for AAPCS-VFP. rdar://9877866 llvm-svn: 161790
2012-08-14 05:23:55 +08:00
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK-LABEL: define arm_aapcs_vfpcc void @f33(%struct.s33* byval(%struct.s33) align 4 %s)
ARM: enable struct byval for AAPCS-VFP. rdar://9877866 llvm-svn: 161790
2012-08-14 05:23:55 +08:00
struct s33 { char buf[32*32]; };
void f33(struct s33 s) { }
AAPCS: Do not split structs after CPRC allocated on stack According to the AAPCS, we can split structs between GPRs and the stack, except for when an argument has already been allocated on the stack. This can occur when a large number of floating-point arguments fill up the VFP registers, and are alllocated on the stack before the general-purpose argument registers are full. llvm-svn: 201137
2014-02-11 17:25:50 +08:00
typedef struct { long long x; int y; } struct_long_long_int;
// CHECK: define arm_aapcs_vfpcc void @test_vfp_stack_gpr_split_1(double %a, double %b, double %c, double %d, double %e, double %f, double %g, double %h, double %i, i32 %j, i64 %k, i32 %l)
void test_vfp_stack_gpr_split_1(double a, double b, double c, double d, double e, double f, double g, double h, double i, int j, long long k, int l) {}
ARM: Simplify PCS handling. The backend should now be able to handle all AAPCS rules based on argument type, which means Clang no longer has to duplicate the register-counting logic and the CodeGen can be significantly simplified. llvm-svn: 230349
2015-02-25 01:22:40 +08:00
// CHECK: define arm_aapcs_vfpcc void @test_vfp_stack_gpr_split_2(double %a, double %b, double %c, double %d, double %e, double %f, double %g, double %h, double %i, i32 %j, [2 x i64] %k.coerce)
AAPCS: Do not split structs after CPRC allocated on stack According to the AAPCS, we can split structs between GPRs and the stack, except for when an argument has already been allocated on the stack. This can occur when a large number of floating-point arguments fill up the VFP registers, and are alllocated on the stack before the general-purpose argument registers are full. llvm-svn: 201137
2014-02-11 17:25:50 +08:00
void test_vfp_stack_gpr_split_2(double a, double b, double c, double d, double e, double f, double g, double h, double i, int j, struct_long_long_int k) {}
[CodeGen] Add an alignment attribute to all sret parameters This fixes a miscompile when the parameter is actually underaligned. rdar://58316406 Differential revision: https://reviews.llvm.org/D74183
2020-03-25 00:36:19 +08:00
// CHECK: define arm_aapcs_vfpcc void @test_vfp_stack_gpr_split_3(%struct.struct_long_long_int* noalias sret align 8 %agg.result, double %a, double %b, double %c, double %d, double %e, double %f, double %g, double %h, double %i, [2 x i64] %k.coerce)
AAPCS: Do not split structs after CPRC allocated on stack According to the AAPCS, we can split structs between GPRs and the stack, except for when an argument has already been allocated on the stack. This can occur when a large number of floating-point arguments fill up the VFP registers, and are alllocated on the stack before the general-purpose argument registers are full. llvm-svn: 201137
2014-02-11 17:25:50 +08:00
struct_long_long_int test_vfp_stack_gpr_split_3(double a, double b, double c, double d, double e, double f, double g, double h, double i, struct_long_long_int k) {}
ARM: Fix assertion caused by passing bitfield struct using ABIArgInfo::getExpandWithPadding In cases where a struct must, according to the AAPCS, not be split between general purpose and floating point registers, we use ABIArgInfo::getExpandWithPadding to add the padding arguments. However, ExpandWithPadding does not work if the struct contains bitfields, so we instead must use ABIArgInfo::getDirect. llvm-svn: 208185
2014-05-07 18:39:12 +08:00
typedef struct { int a; int b:4; int c; } struct_int_bitfield_int;
ARM: Simplify PCS handling. The backend should now be able to handle all AAPCS rules based on argument type, which means Clang no longer has to duplicate the register-counting logic and the CodeGen can be significantly simplified. llvm-svn: 230349
2015-02-25 01:22:40 +08:00
// CHECK: define arm_aapcs_vfpcc void @test_test_vfp_stack_gpr_split_bitfield(double %a, double %b, double %c, double %d, double %e, double %f, double %g, double %h, double %i, i32 %j, i32 %k, [3 x i32] %l.coerce)
ARM: Fix assertion caused by passing bitfield struct using ABIArgInfo::getExpandWithPadding In cases where a struct must, according to the AAPCS, not be split between general purpose and floating point registers, we use ABIArgInfo::getExpandWithPadding to add the padding arguments. However, ExpandWithPadding does not work if the struct contains bitfields, so we instead must use ABIArgInfo::getDirect. llvm-svn: 208185
2014-05-07 18:39:12 +08:00
void test_test_vfp_stack_gpr_split_bitfield(double a, double b, double c, double d, double e, double f, double g, double h, double i, int j, int k, struct_int_bitfield_int l) {}
ARM: PCS non-compliance when struct is padded to avoid register/stack split, and requires internal padding When we were padding a struct to avoid splitting it between registers and the stack, we were throwing away the type which the argument should be coerced to. llvm-svn: 209122
2014-05-19 21:10:05 +08:00
// Note: this struct requires internal padding
typedef struct { int x; long long y; } struct_int_long_long;
ARM: Simplify PCS handling. The backend should now be able to handle all AAPCS rules based on argument type, which means Clang no longer has to duplicate the register-counting logic and the CodeGen can be significantly simplified. llvm-svn: 230349
2015-02-25 01:22:40 +08:00
// CHECK: define arm_aapcs_vfpcc void @test_vfp_stack_gpr_split_4(double %a, double %b, double %c, double %d, double %e, double %f, double %g, double %h, double %i, i32 %j, [2 x i64] %k.coerce)
ARM: PCS non-compliance when struct is padded to avoid register/stack split, and requires internal padding When we were padding a struct to avoid splitting it between registers and the stack, we were throwing away the type which the argument should be coerced to. llvm-svn: 209122
2014-05-19 21:10:05 +08:00
void test_vfp_stack_gpr_split_4(double a, double b, double c, double d, double e, double f, double g, double h, double i, int j, struct_int_long_long k) {}
[ARM] Fix AAPCS non-compliance caused by very large structs This is a fix to the code in clang which inserts padding arguments to ensure that the ARM backend can emit AAPCS-VFP compliant code. This code needs to track the number of registers which have been allocated in order to do this. When passing a very large struct (>64 bytes) by value, clang emits IR which takes a pointer to the struct, but the backend converts this back to passing the struct in registers and on the stack. The bug was that this was being considered by clang to only use one register, meaning that there were situations in which padding arguments were incorrectly emitted by clang. llvm-svn: 211898
2014-06-27 21:59:27 +08:00
// This very large struct (passed byval) uses up the GPRs, so no padding is needed
typedef struct { int x[17]; } struct_seventeen_ints;
typedef struct { int x[4]; } struct_four_ints;
LLVM IR: Generate new-style byval-with-Type from Clang LLVM IR recently added a Type parameter to the byval Attribute, so that when pointers become opaque and no longer have an element type the information will still be present in IR. For now the Type parameter is optional (which is why Clang didn't need this change at the time), but it will become mandatory soon. llvm-svn: 362652
2019-06-06 05:12:14 +08:00
// CHECK: define arm_aapcs_vfpcc void @test_vfp_stack_gpr_split_5(%struct.struct_seventeen_ints* byval(%struct.struct_seventeen_ints) align 4 %a, double %b, double %c, double %d, double %e, double %f, double %g, double %h, double %i, double %j, [4 x i32] %k.coerce)
[ARM] Fix AAPCS non-compliance caused by very large structs This is a fix to the code in clang which inserts padding arguments to ensure that the ARM backend can emit AAPCS-VFP compliant code. This code needs to track the number of registers which have been allocated in order to do this. When passing a very large struct (>64 bytes) by value, clang emits IR which takes a pointer to the struct, but the backend converts this back to passing the struct in registers and on the stack. The bug was that this was being considered by clang to only use one register, meaning that there were situations in which padding arguments were incorrectly emitted by clang. llvm-svn: 211898
2014-06-27 21:59:27 +08:00
void test_vfp_stack_gpr_split_5(struct_seventeen_ints a, double b, double c, double d, double e, double f, double g, double h, double i, double j, struct_four_ints k) {}
[ARM] Fix AAPCS regression caused by r211898 r211898 introduced a regression where a large struct, which would normally be passed ByVal, was causing padding to be inserted to prevent the backend from using some GPRs, in order to follow the AAPCS. However, the type of the argument was not being set correctly, so the backend cannot align 8-byte aligned struct types on the stack. The fix is to not insert the padding arguments when the argument is being passed ByVal. llvm-svn: 213359
2014-07-18 17:09:31 +08:00
// Here, parameter k would need padding to prevent it from being split, but it
// is passed ByVal (due to being > 64 bytes), so the backend handles this instead.
void test_vfp_stack_gpr_split_6(double a, double b, double c, double d, double e, double f, double g, double h, double i, int j, struct_seventeen_ints k) {}
LLVM IR: Generate new-style byval-with-Type from Clang LLVM IR recently added a Type parameter to the byval Attribute, so that when pointers become opaque and no longer have an element type the information will still be present in IR. For now the Type parameter is optional (which is why Clang didn't need this change at the time), but it will become mandatory soon. llvm-svn: 362652
2019-06-06 05:12:14 +08:00
// CHECK: define arm_aapcs_vfpcc void @test_vfp_stack_gpr_split_6(double %a, double %b, double %c, double %d, double %e, double %f, double %g, double %h, double %i, i32 %j, %struct.struct_seventeen_ints* byval(%struct.struct_seventeen_ints) align 4 %k)