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]]
[APFloat] Switch from (PPCDoubleDoubleImpl, IEEEdouble) layout to (IEEEdouble, IEEEdouble) Summary: This patch changes the layout of DoubleAPFloat, and adjust all operations to do either: 1) (IEEEdouble, IEEEdouble) -> (uint64_t, uint64_t) -> PPCDoubleDoubleImpl, then run the old algorithm. 2) Do the right thing directly. 1) includes multiply, divide, remainder, mod, fusedMultiplyAdd, roundToIntegral, convertFromString, next, convertToInteger, convertFromAPInt, convertFromSignExtendedInteger, convertFromZeroExtendedInteger, convertToHexString, toString, getExactInverse. 2) includes makeZero, makeLargest, makeSmallest, makeSmallestNormalized, compare, bitwiseIsEqual, bitcastToAPInt, isDenormal, isSmallest, isLargest, isInteger, ilogb, scalbn, frexp, hash_value, Profile. I could split this into two patches, e.g. use 1) for all operatoins first, then incrementally change some of them to 2). I didn't do that, because 1) involves code that converts data between PPCDoubleDoubleImpl and (IEEEdouble, IEEEdouble) back and forth, and may pessimize the compiler. Instead, I find easy functions and use approach 2) for them directly. Next step is to implement move multiply and divide from 1) to 2). I don't have plans for other functions in 1). Differential Revision: https://reviews.llvm.org/D27872 llvm-svn: 292839
2017-01-24 06:39:35 +08:00
// CHECK: store ppc_fp128 0xMC0040000000000008000000000000000, 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
Cleanup the handling of noinline function attributes, -fno-inline, -fno-inline-functions, -O0, and optnone. These were really, really tangled together: - We used the noinline LLVM attribute for -fno-inline - But not for -fno-inline-functions (breaking LTO) - But we did use it for -finline-hint-functions (yay, LTO is happy!) - But we didn't for -O0 (LTO is sad yet again...) - We had weird structuring of CodeGenOpts with both an inlining enumeration and a boolean. They interacted in weird ways and needlessly. - A *lot* of set smashing went on with setting these, and then got worse when we considered optnone and other inlining-effecting attributes. - A bunch of inline affecting attributes were managed in a completely different place from -fno-inline. - Even with -fno-inline we failed to put the LLVM noinline attribute onto many generated function definitions because they didn't show up as AST-level functions. - If you passed -O0 but -finline-functions we would run the normal inliner pass in LLVM despite it being in the O0 pipeline, which really doesn't make much sense. - Lastly, we used things like '-fno-inline' to manipulate the pass pipeline which forced the pass pipeline to be much more parameterizable than it really needs to be. Instead we can *just* use the optimization level to select a pipeline and control the rest via attributes. Sadly, this causes a bunch of churn in tests because we don't run the optimizer in the tests and check the contents of attribute sets. It would be awesome if attribute sets were a bit more FileCheck friendly, but oh well. I think this is a significant improvement and should remove the semantic need to change what inliner pass we run in order to comply with the requested inlining semantics by relying completely on attributes. It also cleans up tho optnone and related handling a bit. One unfortunate aspect of this is that for generating alwaysinline routines like those in OpenMP we end up removing noinline and then adding alwaysinline. I tried a bunch of other approaches, but because we recompute function attributes from scratch and don't have a declaration here I couldn't find anything substantially cleaner than this. Differential Revision: https://reviews.llvm.org/D28053 llvm-svn: 290398
2016-12-23 09:24:49 +08:00
// CHECK: attributes [[NUW]] = { noinline nounwind{{.*}} }