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/aarch64-varargs.c

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

898 lines
55 KiB
C
Raw Normal View History

[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC) This adds -no-opaque-pointers to clang tests whose output will change when opaque pointers are enabled by default. This is intended to be part of the migration approach described in https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322/9. The patch has been produced by replacing %clang_cc1 with %clang_cc1 -no-opaque-pointers for tests that fail with opaque pointers enabled. Worth noting that this doesn't cover all tests, there's a remaining ~40 tests not using %clang_cc1 that will need a followup change. Differential Revision: https://reviews.llvm.org/D123115
2022-04-07 18:03:55 +08:00
// RUN: %clang_cc1 -no-opaque-pointers -triple arm64-linux-gnu -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=CHECK-LE %s
// RUN: %clang_cc1 -no-opaque-pointers -triple aarch64_be-linux-gnu -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=CHECK-BE %s
AArch64_be varargs processing for ARM ABI llvm-svn: 203917
2014-03-14 19:51:06 +08:00
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
#include <stdarg.h>
// Obviously there's more than one way to implement va_arg. This test should at
// least prevent unintentional regressions caused by refactoring.
va_list the_list;
int simple_int(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} i32 @simple_int
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
return va_arg(the_list, int);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 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: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
// CHECK-BE: [[REG_ADDR_ALIGNED:%[0-9]+]] = getelementptr inbounds i8, i8* [[REG_ADDR]], i64 4
// CHECK-BE: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR_ALIGNED]] to i32*
// CHECK-LE: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to i32*
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
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: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
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-BE: [[STACK_ALIGNED:%[a-z_0-9]*]] = getelementptr inbounds i8, i8* [[STACK]], i64 4
// CHECK-BE: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK_ALIGNED]] to i32*
// CHECK-LE: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to i32*
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi i32* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK: [[RESULT:%[a-z_0-9]+]] = load i32, i32* [[ADDR]]
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: ret i32 [[RESULT]]
}
__int128 aligned_int(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} i128 @aligned_int
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
return va_arg(the_list, __int128);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[ALIGN_REGOFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 15
// CHECK: [[ALIGNED_REGOFFS:%[a-z_0-9]+]] = and i32 [[ALIGN_REGOFFS]], -16
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[ALIGNED_REGOFFS]], 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 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: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[ALIGNED_REGOFFS]]
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to i128*
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[STACKINT:%[a-z_0-9]+]] = ptrtoint i8* [[STACK]] to i64
// CHECK: [[ALIGN_STACK:%[a-z_0-9]+]] = add i64 [[STACKINT]], 15
// CHECK: [[ALIGNED_STACK_INT:%[a-z_0-9]+]] = and i64 [[ALIGN_STACK]], -16
// CHECK: [[ALIGNED_STACK_PTR:%[a-z_0-9]+]] = inttoptr i64 [[ALIGNED_STACK_INT]] to i8*
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: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[ALIGNED_STACK_PTR]], i64 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[ALIGNED_STACK_PTR]] to i128*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi i128* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK: [[RESULT:%[a-z_0-9]+]] = load i128, i128* [[ADDR]]
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: ret i128 [[RESULT]]
}
struct bigstruct {
int a[10];
};
struct bigstruct simple_indirect(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} void @simple_indirect
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
return va_arg(the_list, struct bigstruct);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK-NOT: and i32
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 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: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to %struct.bigstruct**
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK-NOT: and i64
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: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to %struct.bigstruct**
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi %struct.bigstruct** [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK: load %struct.bigstruct*, %struct.bigstruct** [[ADDR]]
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
}
struct aligned_bigstruct {
float a;
long double b;
};
struct aligned_bigstruct simple_aligned_indirect(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} void @simple_aligned_indirect
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
return va_arg(the_list, struct aligned_bigstruct);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 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: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to %struct.aligned_bigstruct**
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
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: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to %struct.aligned_bigstruct**
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi %struct.aligned_bigstruct** [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK: load %struct.aligned_bigstruct*, %struct.aligned_bigstruct** [[ADDR]]
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
}
double simple_double(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} double @simple_double
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
return va_arg(the_list, double);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[VR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 4)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[VR_OFFS]], 0
clang/test/CodeGen/aarch64-varargs.c: works now regardless of assertions. llvm-svn: 203944
2014-03-15 00:30:06 +08:00
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG]]
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[VR_OFFS]], 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 4)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 2)
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: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[VR_OFFS]]
// CHECK-BE: [[REG_ADDR_ALIGNED:%[a-z_0-9]*]] = getelementptr inbounds i8, i8* [[REG_ADDR]], i64 8
// CHECK-BE: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR_ALIGNED]] to double*
// CHECK-LE: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to double*
clang/test/CodeGen/aarch64-varargs.c: works now regardless of assertions. llvm-svn: 203944
2014-03-15 00:30:06 +08:00
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
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: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to double*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi double* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK: [[RESULT:%[a-z_0-9]+]] = load double, double* [[ADDR]]
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: ret double [[RESULT]]
}
struct hfa {
float a, b;
};
struct hfa simple_hfa(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} %struct.hfa @simple_hfa
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
return va_arg(the_list, struct hfa);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[VR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 4)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[VR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[VR_OFFS]], 32
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 4)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 2)
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: [[FIRST_REG:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[VR_OFFS]]
// CHECK-LE: [[EL_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[FIRST_REG]], i64 0
// CHECK-BE: [[EL_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[FIRST_REG]], i64 12
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[EL_TYPED:%[a-z_0-9]+]] = bitcast i8* [[EL_ADDR]] to float*
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: [[EL_TMPADDR:%[a-z_0-9]+]] = getelementptr inbounds [2 x float], [2 x float]* %[[TMP_HFA:[a-z_.0-9]+]], i64 0, i64 0
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK: [[EL:%[a-z_0-9]+]] = load float, float* [[EL_TYPED]]
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: store float [[EL]], float* [[EL_TMPADDR]]
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-LE: [[EL_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[FIRST_REG]], i64 16
// CHECK-BE: [[EL_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[FIRST_REG]], i64 28
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[EL_TYPED:%[a-z_0-9]+]] = bitcast i8* [[EL_ADDR]] to float*
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: [[EL_TMPADDR:%[a-z_0-9]+]] = getelementptr inbounds [2 x float], [2 x float]* %[[TMP_HFA]], i64 0, i64 1
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK: [[EL:%[a-z_0-9]+]] = load float, float* [[EL_TYPED]]
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: store float [[EL]], float* [[EL_TMPADDR]]
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast [2 x float]* %[[TMP_HFA]] to %struct.hfa*
// CHECK: br label %[[VAARG_END:[a-z_.0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
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: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to %struct.hfa*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi %struct.hfa* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
}
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// Over and under alignment on fundamental types has no effect on parameter
// passing, so the code generated for va_arg should be the same as for
// non-aligned fundamental types.
typedef int underaligned_int __attribute__((packed,aligned(2)));
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
underaligned_int underaligned_int_test(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} i32 @underaligned_int_test()
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, underaligned_int);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
// CHECK-BE: [[REG_ADDR_ALIGNED:%[0-9]+]] = getelementptr inbounds i8, i8* [[REG_ADDR]], i64 4
// CHECK-BE: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR_ALIGNED]] to i32*
// CHECK-LE: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to i32*
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK-BE: [[STACK_ALIGNED:%[a-z_0-9]*]] = getelementptr inbounds i8, i8* [[STACK]], i64 4
// CHECK-BE: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK_ALIGNED]] to i32*
// CHECK-LE: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to i32*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi i32* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
// CHECK: [[RESULT:%[a-z_0-9]+]] = load i32, i32* [[ADDR]]
// CHECK: ret i32 [[RESULT]]
}
typedef int overaligned_int __attribute__((aligned(32)));
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
overaligned_int overaligned_int_test(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} i32 @overaligned_int_test()
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, overaligned_int);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
// CHECK-BE: [[REG_ADDR_ALIGNED:%[0-9]+]] = getelementptr inbounds i8, i8* [[REG_ADDR]], i64 4
// CHECK-BE: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR_ALIGNED]] to i32*
// CHECK-LE: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to i32*
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK-BE: [[STACK_ALIGNED:%[a-z_0-9]*]] = getelementptr inbounds i8, i8* [[STACK]], i64 4
// CHECK-BE: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK_ALIGNED]] to i32*
// CHECK-LE: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to i32*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi i32* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
// CHECK: [[RESULT:%[a-z_0-9]+]] = load i32, i32* [[ADDR]]
// CHECK: ret i32 [[RESULT]]
}
typedef long long underaligned_long_long __attribute__((packed,aligned(2)));
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
underaligned_long_long underaligned_long_long_test(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} i64 @underaligned_long_long_test()
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, underaligned_long_long);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to i64*
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to i64*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi i64* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
// CHECK: [[RESULT:%[a-z_0-9]+]] = load i64, i64* [[ADDR]]
// CHECK: ret i64 [[RESULT]]
}
typedef long long overaligned_long_long __attribute__((aligned(32)));
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
overaligned_long_long overaligned_long_long_test(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} i64 @overaligned_long_long_test()
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, overaligned_long_long);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to i64*
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to i64*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi i64* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
// CHECK: [[RESULT:%[a-z_0-9]+]] = load i64, i64* [[ADDR]]
// CHECK: ret i64 [[RESULT]]
}
typedef __int128 underaligned_int128 __attribute__((packed,aligned(2)));
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
underaligned_int128 underaligned_int128_test(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} i128 @underaligned_int128_test()
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, underaligned_int128);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[ALIGN_REGOFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 15
// CHECK: [[ALIGNED_REGOFFS:%[a-z_0-9]+]] = and i32 [[ALIGN_REGOFFS]], -16
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[ALIGNED_REGOFFS]], 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[ALIGNED_REGOFFS]]
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to i128*
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[STACKINT:%[a-z_0-9]+]] = ptrtoint i8* [[STACK]] to i64
// CHECK: [[ALIGN_STACK:%[a-z_0-9]+]] = add i64 [[STACKINT]], 15
// CHECK: [[ALIGNED_STACK_INT:%[a-z_0-9]+]] = and i64 [[ALIGN_STACK]], -16
// CHECK: [[ALIGNED_STACK_PTR:%[a-z_0-9]+]] = inttoptr i64 [[ALIGNED_STACK_INT]] to i8*
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[ALIGNED_STACK_PTR]], i64 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[ALIGNED_STACK_PTR]] to i128*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi i128* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
// CHECK: [[RESULT:%[a-z_0-9]+]] = load i128, i128* [[ADDR]]
// CHECK: ret i128 [[RESULT]]
}
typedef __int128 overaligned_int128 __attribute__((aligned(32)));
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
overaligned_int128 overaligned_int128_test(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} i128 @overaligned_int128_test()
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, overaligned_int128);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[ALIGN_REGOFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 15
// CHECK: [[ALIGNED_REGOFFS:%[a-z_0-9]+]] = and i32 [[ALIGN_REGOFFS]], -16
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[ALIGNED_REGOFFS]], 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[ALIGNED_REGOFFS]]
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to i128*
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[STACKINT:%[a-z_0-9]+]] = ptrtoint i8* [[STACK]] to i64
// CHECK: [[ALIGN_STACK:%[a-z_0-9]+]] = add i64 [[STACKINT]], 15
// CHECK: [[ALIGNED_STACK_INT:%[a-z_0-9]+]] = and i64 [[ALIGN_STACK]], -16
// CHECK: [[ALIGNED_STACK_PTR:%[a-z_0-9]+]] = inttoptr i64 [[ALIGNED_STACK_INT]] to i8*
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[ALIGNED_STACK_PTR]], i64 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[ALIGNED_STACK_PTR]] to i128*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi i128* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
// CHECK: [[RESULT:%[a-z_0-9]+]] = load i128, i128* [[ADDR]]
// CHECK: ret i128 [[RESULT]]
}
// The way that attributes applied to a struct change parameter passing is a
// little strange, in that the alignment due to attributes is used when
// calculating the size of the struct, but the alignment is based only on the
// alignment of the members (which can be affected by attributes). What this
// means is:
// * The only effect of the aligned attribute on a struct is to increase its
// size if the alignment is greater than the member alignment.
// * The packed attribute is considered as applying to the members, so it will
// affect the alignment.
// Additionally the alignment can't go below 8 or above 16, so it's only
// __int128 that can be affected by a change in alignment.
typedef struct __attribute__((packed,aligned(2))) {
int val;
} underaligned_int_struct;
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
underaligned_int_struct underaligned_int_struct_test(void) {
[Clang][AArch64] Disable rounding of return values for AArch64 If a return value is explicitly rounded to 64 bits, an additional zext instruction is emitted, and in some cases it prevents tail call optimization. As discussed in D100225, this rounding is not necessary and can be disabled. Differential Revision: https://reviews.llvm.org/D100591
2021-04-13 21:28:32 +08:00
// CHECK-LE-LABEL: define{{.*}} i32 @underaligned_int_struct_test()
// CHECK-BE-LABEL: define{{.*}} i64 @underaligned_int_struct_test()
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, underaligned_int_struct);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to %struct.underaligned_int_struct*
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to %struct.underaligned_int_struct*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi %struct.underaligned_int_struct* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
}
typedef struct __attribute__((aligned(16))) {
int val;
} overaligned_int_struct;
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
overaligned_int_struct overaligned_int_struct_test(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} i128 @overaligned_int_struct_test()
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, overaligned_int_struct);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to %struct.overaligned_int_struct*
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to %struct.overaligned_int_struct*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi %struct.overaligned_int_struct* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
}
typedef struct __attribute__((packed,aligned(2))) {
long long val;
} underaligned_long_long_struct;
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
underaligned_long_long_struct underaligned_long_long_struct_test(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} i64 @underaligned_long_long_struct_test()
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, underaligned_long_long_struct);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to %struct.underaligned_long_long_struct*
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to %struct.underaligned_long_long_struct*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi %struct.underaligned_long_long_struct* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
}
typedef struct __attribute__((aligned(16))) {
long long val;
} overaligned_long_long_struct;
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
overaligned_long_long_struct overaligned_long_long_struct_test(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} i128 @overaligned_long_long_struct_test()
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, overaligned_long_long_struct);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to %struct.overaligned_long_long_struct*
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to %struct.overaligned_long_long_struct*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi %struct.overaligned_long_long_struct* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
}
typedef struct __attribute__((packed,aligned(2))) {
__int128 val;
} underaligned_int128_struct;
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
underaligned_int128_struct underaligned_int128_struct_test(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} [2 x i64] @underaligned_int128_struct_test()
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, underaligned_int128_struct);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to %struct.underaligned_int128_struct*
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to %struct.underaligned_int128_struct*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi %struct.underaligned_int128_struct* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
}
// Overaligning to 32 bytes causes it to be passed indirectly via a pointer
typedef struct __attribute__((aligned(32))) {
__int128 val;
} overaligned_int128_struct;
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
overaligned_int128_struct overaligned_int128_struct_test(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} void @overaligned_int128_struct_test(%struct.overaligned_int128_struct* noalias sret(%struct.overaligned_int128_struct) align 32 %agg.result)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, overaligned_int128_struct);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to %struct.overaligned_int128_struct**
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to %struct.overaligned_int128_struct**
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi %struct.overaligned_int128_struct** [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
}
// Overaligning or underaligning a struct member changes both its alignment and
// size when passed as an argument.
typedef struct {
int val __attribute__((packed,aligned(2)));
} underaligned_int_struct_member;
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
underaligned_int_struct_member underaligned_int_struct_member_test(void) {
[Clang][AArch64] Disable rounding of return values for AArch64 If a return value is explicitly rounded to 64 bits, an additional zext instruction is emitted, and in some cases it prevents tail call optimization. As discussed in D100225, this rounding is not necessary and can be disabled. Differential Revision: https://reviews.llvm.org/D100591
2021-04-13 21:28:32 +08:00
// CHECK-LE-LABEL: define{{.*}} i32 @underaligned_int_struct_member_test()
// CHECK-BE-LABEL: define{{.*}} i64 @underaligned_int_struct_member_test()
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, underaligned_int_struct_member);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to %struct.underaligned_int_struct_member*
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to %struct.underaligned_int_struct_member*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi %struct.underaligned_int_struct_member* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
}
typedef struct {
int val __attribute__((aligned(16)));
} overaligned_int_struct_member;
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
overaligned_int_struct_member overaligned_int_struct_member_test(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} i128 @overaligned_int_struct_member_test()
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, overaligned_int_struct_member);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[ALIGN_REGOFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 15
// CHECK: [[ALIGNED_REGOFFS:%[a-z_0-9]+]] = and i32 [[ALIGN_REGOFFS]], -16
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[ALIGNED_REGOFFS]], 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[ALIGNED_REGOFFS]]
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to %struct.overaligned_int_struct_member*
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[STACKINT:%[a-z_0-9]+]] = ptrtoint i8* [[STACK]] to i64
// CHECK: [[ALIGN_STACK:%[a-z_0-9]+]] = add i64 [[STACKINT]], 15
// CHECK: [[ALIGNED_STACK_INT:%[a-z_0-9]+]] = and i64 [[ALIGN_STACK]], -16
// CHECK: [[ALIGNED_STACK_PTR:%[a-z_0-9]+]] = inttoptr i64 [[ALIGNED_STACK_INT]] to i8*
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[ALIGNED_STACK_PTR]], i64 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[ALIGNED_STACK_PTR]] to %struct.overaligned_int_struct_member*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi %struct.overaligned_int_struct_member* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
}
typedef struct {
long long val __attribute__((packed,aligned(2)));
} underaligned_long_long_struct_member;
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
underaligned_long_long_struct_member underaligned_long_long_struct_member_test(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} i64 @underaligned_long_long_struct_member_test()
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, underaligned_long_long_struct_member);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to %struct.underaligned_long_long_struct_member*
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to %struct.underaligned_long_long_struct_member*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi %struct.underaligned_long_long_struct_member* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
}
typedef struct {
long long val __attribute__((aligned(16)));
} overaligned_long_long_struct_member;
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
overaligned_long_long_struct_member overaligned_long_long_struct_member_test(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} i128 @overaligned_long_long_struct_member_test()
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, overaligned_long_long_struct_member);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[ALIGN_REGOFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 15
// CHECK: [[ALIGNED_REGOFFS:%[a-z_0-9]+]] = and i32 [[ALIGN_REGOFFS]], -16
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[ALIGNED_REGOFFS]], 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[ALIGNED_REGOFFS]]
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to %struct.overaligned_long_long_struct_member*
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[STACKINT:%[a-z_0-9]+]] = ptrtoint i8* [[STACK]] to i64
// CHECK: [[ALIGN_STACK:%[a-z_0-9]+]] = add i64 [[STACKINT]], 15
// CHECK: [[ALIGNED_STACK_INT:%[a-z_0-9]+]] = and i64 [[ALIGN_STACK]], -16
// CHECK: [[ALIGNED_STACK_PTR:%[a-z_0-9]+]] = inttoptr i64 [[ALIGNED_STACK_INT]] to i8*
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[ALIGNED_STACK_PTR]], i64 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[ALIGNED_STACK_PTR]] to %struct.overaligned_long_long_struct_member*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi %struct.overaligned_long_long_struct_member* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
}
typedef struct {
__int128 val __attribute__((packed,aligned(2)));
} underaligned_int128_struct_member;
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
underaligned_int128_struct_member underaligned_int128_struct_member_test(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} [2 x i64] @underaligned_int128_struct_member_test()
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, underaligned_int128_struct_member);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to %struct.underaligned_int128_struct_member*
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 16
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to %struct.underaligned_int128_struct_member*
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi %struct.underaligned_int128_struct_member* [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
}
// Overaligning to 32 bytes causes it to be passed indirectly via a pointer
typedef struct {
__int128 val __attribute__((aligned(32)));
} overaligned_int128_struct_member;
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
overaligned_int128_struct_member overaligned_int128_struct_member_test(void) {
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK-LABEL: define{{.*}} void @overaligned_int128_struct_member_test(%struct.overaligned_int128_struct_member* noalias sret(%struct.overaligned_int128_struct_member) align 32 %agg.result)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
return va_arg(the_list, overaligned_int128_struct_member);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
// CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
// CHECK: [[VAARG_MAYBE_REG]]
// CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
// CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
// CHECK: [[VAARG_IN_REG]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
// CHECK: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR]] to %struct.overaligned_int128_struct_member**
// CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
// CHECK: [[VAARG_ON_STACK]]
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 8
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
[ARM][AArch64] Fix incorrect handling of alignment in va_arg code generation Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
2019-05-22 19:42:54 +08:00
// CHECK: [[FROMSTACK_ADDR:%[a-z_0-9]+]] = bitcast i8* [[STACK]] to %struct.overaligned_int128_struct_member**
// CHECK: br label %[[VAARG_END]]
// CHECK: [[VAARG_END]]
// CHECK: [[ADDR:%[a-z._0-9]+]] = phi %struct.overaligned_int128_struct_member** [ [[FROMREG_ADDR]], %[[VAARG_IN_REG]] ], [ [[FROMSTACK_ADDR]], %[[VAARG_ON_STACK]] ]
}
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
void check_start(int n, ...) {
[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions. I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default. Test updates are made as a separate patch: D108453 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105169
2022-01-16 17:53:11 +08:00
// CHECK-LABEL: define{{.*}} void @check_start(i32 noundef %n, ...)
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
va_list the_list;
va_start(the_list, n);
AST: Move __va_list tag back to std conditionally on AArch64. In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
2022-01-07 05:37:21 +08:00
// CHECK: [[THE_LIST:%[a-z_0-9]+]] = alloca %struct.__va_list
// CHECK: [[VOIDP_THE_LIST:%[a-z_0-9]+]] = bitcast %struct.__va_list* [[THE_LIST]] to i8*
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
// CHECK: call void @llvm.va_start(i8* [[VOIDP_THE_LIST]])
}