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/ppc64-complex-parms.c

184 lines
9.1 KiB
C
Raw Normal View History

This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu -emit-llvm -o - %s | FileCheck %s
float crealf(_Complex float);
double creal(_Complex double);
long double creall(_Complex long double);
float foo_float(_Complex float x) {
return crealf(x);
}
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: define float @foo_float(float {{[%A-Za-z0-9.]+}}, float {{[%A-Za-z0-9.]+}}) [[NUW:#[0-9]+]] {
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
double foo_double(_Complex double x) {
return creal(x);
}
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: define double @foo_double(double {{[%A-Za-z0-9.]+}}, double {{[%A-Za-z0-9.]+}}) [[NUW]] {
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
long double foo_long_double(_Complex long double x) {
return creall(x);
}
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: define ppc_fp128 @foo_long_double(ppc_fp128 {{[%A-Za-z0-9.]+}}, ppc_fp128 {{[%A-Za-z0-9.]+}}) [[NUW]] {
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
int foo_int(_Complex int x) {
return __real__ x;
}
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: define signext i32 @foo_int(i32 {{[%A-Za-z0-9.]+}}, i32 {{[%A-Za-z0-9.]+}}) [[NUW]] {
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
short foo_short(_Complex short x) {
return __real__ x;
}
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: define signext i16 @foo_short(i16 {{[%A-Za-z0-9.]+}}, i16 {{[%A-Za-z0-9.]+}}) [[NUW]] {
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
signed char foo_char(_Complex signed char x) {
return __real__ x;
}
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: define signext i8 @foo_char(i8 {{[%A-Za-z0-9.]+}}, i8 {{[%A-Za-z0-9.]+}}) [[NUW]] {
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
long foo_long(_Complex long x) {
return __real__ x;
}
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: define i64 @foo_long(i64 {{[%A-Za-z0-9.]+}}, i64 {{[%A-Za-z0-9.]+}}) [[NUW]] {
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
long long foo_long_long(_Complex long long x) {
return __real__ x;
}
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: define i64 @foo_long_long(i64 {{[%A-Za-z0-9.]+}}, i64 {{[%A-Za-z0-9.]+}}) [[NUW]] {
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
void bar_float(void) {
foo_float(2.0f - 2.5fi);
}
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: define void @bar_float() [[NUW]] {
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: %[[VAR1:[A-Za-z0-9.]+]] = alloca { float, float }, align 4
Update Clang tests to handle explicitly typed gep changes in LLVM. llvm-svn: 230783
2015-02-28 03:18:17 +08:00
// CHECK: %[[VAR2:[A-Za-z0-9.]+]] = getelementptr inbounds { float, float }, { float, float }* %[[VAR1]], i32 0, i32 0
// CHECK: %[[VAR3:[A-Za-z0-9.]+]] = getelementptr inbounds { float, float }, { float, float }* %[[VAR1]], i32 0, i32 1
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: store float 2.000000e+00, float* %[[VAR2]]
// CHECK: store float -2.500000e+00, float* %[[VAR3]]
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// CHECK: %[[VAR4:[A-Za-z0-9.]+]] = getelementptr inbounds { float, float }, { float, float }* %[[VAR1]], i32 0, i32 0
// CHECK: %[[VAR5:[A-Za-z0-9.]+]] = load float, float* %[[VAR4]], align 4
// CHECK: %[[VAR6:[A-Za-z0-9.]+]] = getelementptr inbounds { float, float }, { float, float }* %[[VAR1]], i32 0, i32 1
// CHECK: %[[VAR7:[A-Za-z0-9.]+]] = load float, float* %[[VAR6]], align 4
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: %{{[A-Za-z0-9.]+}} = call float @foo_float(float %[[VAR5]], float %[[VAR7]])
void bar_double(void) {
foo_double(2.0 - 2.5i);
}
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: define void @bar_double() [[NUW]] {
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: %[[VAR11:[A-Za-z0-9.]+]] = alloca { double, double }, align 8
Update Clang tests to handle explicitly typed gep changes in LLVM. llvm-svn: 230783
2015-02-28 03:18:17 +08:00
// CHECK: %[[VAR12:[A-Za-z0-9.]+]] = getelementptr inbounds { double, double }, { double, double }* %[[VAR11]], i32 0, i32 0
// CHECK: %[[VAR13:[A-Za-z0-9.]+]] = getelementptr inbounds { double, double }, { double, double }* %[[VAR11]], i32 0, i32 1
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: store double 2.000000e+00, double* %[[VAR12]]
// CHECK: store double -2.500000e+00, double* %[[VAR13]]
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// CHECK: %[[VAR14:[A-Za-z0-9.]+]] = getelementptr inbounds { double, double }, { double, double }* %[[VAR11]], i32 0, i32 0
// CHECK: %[[VAR15:[A-Za-z0-9.]+]] = load double, double* %[[VAR14]], align 8
// CHECK: %[[VAR16:[A-Za-z0-9.]+]] = getelementptr inbounds { double, double }, { double, double }* %[[VAR11]], i32 0, i32 1
// CHECK: %[[VAR17:[A-Za-z0-9.]+]] = load double, double* %[[VAR16]], align 8
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: %{{[A-Za-z0-9.]+}} = call double @foo_double(double %[[VAR15]], double %[[VAR17]])
void bar_long_double(void) {
foo_long_double(2.0L - 2.5Li);
}
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: define void @bar_long_double() [[NUW]] {
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: %[[VAR21:[A-Za-z0-9.]+]] = alloca { ppc_fp128, ppc_fp128 }, align 16
Update Clang tests to handle explicitly typed gep changes in LLVM. llvm-svn: 230783
2015-02-28 03:18:17 +08:00
// CHECK: %[[VAR22:[A-Za-z0-9.]+]] = getelementptr inbounds { ppc_fp128, ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %[[VAR21]], i32 0, i32 0
// CHECK: %[[VAR23:[A-Za-z0-9.]+]] = getelementptr inbounds { ppc_fp128, ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %[[VAR21]], i32 0, i32 1
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: store ppc_fp128 0xM40000000000000000000000000000000, ppc_fp128* %[[VAR22]]
// CHECK: store ppc_fp128 0xMC0040000000000000000000000000000, ppc_fp128* %[[VAR23]]
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// CHECK: %[[VAR24:[A-Za-z0-9.]+]] = getelementptr inbounds { ppc_fp128, ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %[[VAR21]], i32 0, i32 0
// CHECK: %[[VAR25:[A-Za-z0-9.]+]] = load ppc_fp128, ppc_fp128* %[[VAR24]], align 16
// CHECK: %[[VAR26:[A-Za-z0-9.]+]] = getelementptr inbounds { ppc_fp128, ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %[[VAR21]], i32 0, i32 1
// CHECK: %[[VAR27:[A-Za-z0-9.]+]] = load ppc_fp128, ppc_fp128* %[[VAR26]], align 16
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: %{{[A-Za-z0-9.]+}} = call ppc_fp128 @foo_long_double(ppc_fp128 %[[VAR25]], ppc_fp128 %[[VAR27]])
void bar_int(void) {
foo_int(2 - 3i);
}
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: define void @bar_int() [[NUW]] {
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: %[[VAR31:[A-Za-z0-9.]+]] = alloca { i32, i32 }, align 4
Update Clang tests to handle explicitly typed gep changes in LLVM. llvm-svn: 230783
2015-02-28 03:18:17 +08:00
// CHECK: %[[VAR32:[A-Za-z0-9.]+]] = getelementptr inbounds { i32, i32 }, { i32, i32 }* %[[VAR31]], i32 0, i32 0
// CHECK: %[[VAR33:[A-Za-z0-9.]+]] = getelementptr inbounds { i32, i32 }, { i32, i32 }* %[[VAR31]], i32 0, i32 1
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: store i32 2, i32* %[[VAR32]]
// CHECK: store i32 -3, i32* %[[VAR33]]
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// CHECK: %[[VAR34:[A-Za-z0-9.]+]] = getelementptr inbounds { i32, i32 }, { i32, i32 }* %[[VAR31]], i32 0, i32 0
// CHECK: %[[VAR35:[A-Za-z0-9.]+]] = load i32, i32* %[[VAR34]], align 4
// CHECK: %[[VAR36:[A-Za-z0-9.]+]] = getelementptr inbounds { i32, i32 }, { i32, i32 }* %[[VAR31]], i32 0, i32 1
// CHECK: %[[VAR37:[A-Za-z0-9.]+]] = load i32, i32* %[[VAR36]], align 4
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: %{{[A-Za-z0-9.]+}} = call signext i32 @foo_int(i32 %[[VAR35]], i32 %[[VAR37]])
void bar_short(void) {
foo_short(2 - 3i);
}
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: define void @bar_short() [[NUW]] {
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: %[[VAR41:[A-Za-z0-9.]+]] = alloca { i16, i16 }, align 2
Update Clang tests to handle explicitly typed gep changes in LLVM. llvm-svn: 230783
2015-02-28 03:18:17 +08:00
// CHECK: %[[VAR42:[A-Za-z0-9.]+]] = getelementptr inbounds { i16, i16 }, { i16, i16 }* %[[VAR41]], i32 0, i32 0
// CHECK: %[[VAR43:[A-Za-z0-9.]+]] = getelementptr inbounds { i16, i16 }, { i16, i16 }* %[[VAR41]], i32 0, i32 1
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: store i16 2, i16* %[[VAR42]]
// CHECK: store i16 -3, i16* %[[VAR43]]
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// CHECK: %[[VAR44:[A-Za-z0-9.]+]] = getelementptr inbounds { i16, i16 }, { i16, i16 }* %[[VAR41]], i32 0, i32 0
// CHECK: %[[VAR45:[A-Za-z0-9.]+]] = load i16, i16* %[[VAR44]], align 2
// CHECK: %[[VAR46:[A-Za-z0-9.]+]] = getelementptr inbounds { i16, i16 }, { i16, i16 }* %[[VAR41]], i32 0, i32 1
// CHECK: %[[VAR47:[A-Za-z0-9.]+]] = load i16, i16* %[[VAR46]], align 2
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: %{{[A-Za-z0-9.]+}} = call signext i16 @foo_short(i16 %[[VAR45]], i16 %[[VAR47]])
void bar_char(void) {
foo_char(2 - 3i);
}
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: define void @bar_char() [[NUW]] {
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: %[[VAR51:[A-Za-z0-9.]+]] = alloca { i8, i8 }, align 1
Update Clang tests to handle explicitly typed gep changes in LLVM. llvm-svn: 230783
2015-02-28 03:18:17 +08:00
// CHECK: %[[VAR52:[A-Za-z0-9.]+]] = getelementptr inbounds { i8, i8 }, { i8, i8 }* %[[VAR51]], i32 0, i32 0
// CHECK: %[[VAR53:[A-Za-z0-9.]+]] = getelementptr inbounds { i8, i8 }, { i8, i8 }* %[[VAR51]], i32 0, i32 1
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: store i8 2, i8* %[[VAR52]]
// CHECK: store i8 -3, i8* %[[VAR53]]
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// CHECK: %[[VAR54:[A-Za-z0-9.]+]] = getelementptr inbounds { i8, i8 }, { i8, i8 }* %[[VAR51]], i32 0, i32 0
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK: %[[VAR55:[A-Za-z0-9.]+]] = load i8, i8* %[[VAR54]], align 1
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// CHECK: %[[VAR56:[A-Za-z0-9.]+]] = getelementptr inbounds { i8, i8 }, { i8, i8 }* %[[VAR51]], i32 0, i32 1
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK: %[[VAR57:[A-Za-z0-9.]+]] = load i8, i8* %[[VAR56]], align 1
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: %{{[A-Za-z0-9.]+}} = call signext i8 @foo_char(i8 %[[VAR55]], i8 %[[VAR57]])
void bar_long(void) {
foo_long(2L - 3Li);
}
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: define void @bar_long() [[NUW]] {
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: %[[VAR61:[A-Za-z0-9.]+]] = alloca { i64, i64 }, align 8
Update Clang tests to handle explicitly typed gep changes in LLVM. llvm-svn: 230783
2015-02-28 03:18:17 +08:00
// CHECK: %[[VAR62:[A-Za-z0-9.]+]] = getelementptr inbounds { i64, i64 }, { i64, i64 }* %[[VAR61]], i32 0, i32 0
// CHECK: %[[VAR63:[A-Za-z0-9.]+]] = getelementptr inbounds { i64, i64 }, { i64, i64 }* %[[VAR61]], i32 0, i32 1
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: store i64 2, i64* %[[VAR62]]
// CHECK: store i64 -3, i64* %[[VAR63]]
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// CHECK: %[[VAR64:[A-Za-z0-9.]+]] = getelementptr inbounds { i64, i64 }, { i64, i64 }* %[[VAR61]], i32 0, i32 0
// CHECK: %[[VAR65:[A-Za-z0-9.]+]] = load i64, i64* %[[VAR64]], align 8
// CHECK: %[[VAR66:[A-Za-z0-9.]+]] = getelementptr inbounds { i64, i64 }, { i64, i64 }* %[[VAR61]], i32 0, i32 1
// CHECK: %[[VAR67:[A-Za-z0-9.]+]] = load i64, i64* %[[VAR66]], align 8
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: %{{[A-Za-z0-9.]+}} = call i64 @foo_long(i64 %[[VAR65]], i64 %[[VAR67]])
void bar_long_long(void) {
foo_long_long(2LL - 3LLi);
}
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: define void @bar_long_long() [[NUW]] {
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: %[[VAR71:[A-Za-z0-9.]+]] = alloca { i64, i64 }, align 8
Update Clang tests to handle explicitly typed gep changes in LLVM. llvm-svn: 230783
2015-02-28 03:18:17 +08:00
// CHECK: %[[VAR72:[A-Za-z0-9.]+]] = getelementptr inbounds { i64, i64 }, { i64, i64 }* %[[VAR71]], i32 0, i32 0
// CHECK: %[[VAR73:[A-Za-z0-9.]+]] = getelementptr inbounds { i64, i64 }, { i64, i64 }* %[[VAR71]], i32 0, i32 1
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: store i64 2, i64* %[[VAR72]]
// CHECK: store i64 -3, i64* %[[VAR73]]
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// CHECK: %[[VAR74:[A-Za-z0-9.]+]] = getelementptr inbounds { i64, i64 }, { i64, i64 }* %[[VAR71]], i32 0, i32 0
// CHECK: %[[VAR75:[A-Za-z0-9.]+]] = load i64, i64* %[[VAR74]], align 8
// CHECK: %[[VAR76:[A-Za-z0-9.]+]] = getelementptr inbounds { i64, i64 }, { i64, i64 }* %[[VAR71]], i32 0, i32 1
// CHECK: %[[VAR77:[A-Za-z0-9.]+]] = load i64, i64* %[[VAR76]], align 8
This patch addresses an incompatibility relative to the 64-bit PowerPC ELF ABI. Complex values are to be passed in registers as though the real and imaginary parts were passed as separate parameters. Prior to this patch, complex values were passed as byval aggregates. It turns out that specifying getDirect() for all complex types when classifying the argument type results in the desired behavior. The new Clang test case verifies that the correct LLVM IR is generated for caller and callee for each of the underlying types for _Complex. llvm-svn: 168673
2012-11-27 10:46:43 +08:00
// CHECK: %{{[A-Za-z0-9.]+}} = call i64 @foo_long_long(i64 %[[VAR75]], i64 %[[VAR77]])
Modify the tests to use attribute group references instead of listing the function attributes. llvm-svn: 175606
2013-02-20 15:22:19 +08:00
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: attributes [[NUW]] = { nounwind{{.*}} }