maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCXX/cxx0x-initializer-stdinitia...

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

510 lines
21 KiB
C++
Raw Normal View History

Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// RUN: %clang_cc1 -std=c++11 -triple x86_64-none-linux-gnu -fmerge-all-constants -emit-llvm -o - %s | FileCheck -check-prefixes=X86,CHECK %s
// RUN: %clang_cc1 -std=c++11 -triple amdgcn-amd-amdhsa -DNO_TLS -fmerge-all-constants -emit-llvm -o - %s | FileCheck -check-prefixes=AMDGCN,CHECK %s
Basic code generation support for std::initializer_list. We now generate temporary arrays to back std::initializer_list objects initialized with braces. The initializer_list is then made to point at the array. We support both ptr+size and start+end forms, although the latter is untested. Array lifetime is correct for temporary std::initializer_lists (e.g. call arguments) and local variables. It is untested for new expressions and member initializers. Things left to do: Massively increase the amount of testing. I need to write tests for start+end init lists, temporary objects created as a side effect of initializing init list objects, new expressions, member initialization, creation of temporary objects (e.g. std::vector) for initializer lists, and probably more. Get lifetime "right" for member initializers and new expressions. Not that either are very useful. Implement list-initialization of array new expressions. llvm-svn: 150803
2012-02-17 16:42:25 +08:00
namespace std {
typedef decltype(sizeof(int)) size_t;
// libc++'s implementation
template <class _E>
class initializer_list
{
const _E* __begin_;
size_t __size_;
initializer_list(const _E* __b, size_t __s)
: __begin_(__b),
__size_(__s)
{}
public:
typedef _E value_type;
typedef const _E& reference;
typedef const _E& const_reference;
typedef size_t size_type;
typedef const _E* iterator;
typedef const _E* const_iterator;
initializer_list() : __begin_(nullptr), __size_(0) {}
size_t size() const {return __size_;}
const _E* begin() const {return __begin_;}
const _E* end() const {return __begin_ + __size_;}
};
}
CodeGen support for global variables of type std::initializer_list<X>. This emits a backing array with internal linkage and fills it with data, then has the initializer_list point at the array. Dynamic initialization and global destructors are correctly supported. What doesn't work is nested initializer_lists. I have no idea how to get them to work, either. However, these should be very rare, and so I'll just call it a known bug and declare generalized initializers DONE! llvm-svn: 151457
2012-02-26 04:51:20 +08:00
struct destroyme1 {
~destroyme1();
};
struct destroyme2 {
~destroyme2();
};
struct witharg1 {
witharg1(const destroyme1&);
~witharg1();
};
struct wantslist1 {
wantslist1(std::initializer_list<destroyme1>);
~wantslist1();
};
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// X86: @_ZGR15globalInitList1_ = internal constant [3 x i32] [i32 1, i32 2, i32 3]
// X86: @globalInitList1 = global %{{[^ ]+}} { i32* getelementptr inbounds ([3 x i32], [3 x i32]* @_ZGR15globalInitList1_, i32 0, i32 0), i{{32|64}} 3 }
Clean up AMDGCN tests Differential Revision: https://reviews.llvm.org/D43340 llvm-svn: 325279
2018-02-16 03:12:41 +08:00
// AMDGCN: @_ZGR15globalInitList1_ = internal addrspace(1) constant [3 x i32] [i32 1, i32 2, i32 3]
// AMDGCN: @globalInitList1 = addrspace(1) global %{{[^ ]+}} { i32* addrspacecast (i32 addrspace(1)* getelementptr inbounds ([3 x i32], [3 x i32] addrspace(1)* @_ZGR15globalInitList1_, i32 0, i32 0) to i32*), i{{32|64}} 3 }
CodeGen support for global variables of type std::initializer_list<X>. This emits a backing array with internal linkage and fills it with data, then has the initializer_list point at the array. Dynamic initialization and global destructors are correctly supported. What doesn't work is nested initializer_lists. I have no idea how to get them to work, either. However, these should be very rare, and so I'll just call it a known bug and declare generalized initializers DONE! llvm-svn: 151457
2012-02-26 04:51:20 +08:00
std::initializer_list<int> globalInitList1 = {1, 2, 3};
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
#ifndef NO_TLS
CodeGen support for function-local static thread_local variables with non-constant constructors or non-trivial destructors. Plus bugfixes for thread_local references bound to temporaries (the temporaries themselves are lifetime-extended to become thread_local), and the corresponding case for std::initializer_list. llvm-svn: 179496
2013-04-15 07:01:42 +08:00
namespace thread_local_global_array {
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// FIXME: We should be able to constant-evaluate this even though the
// initializer is not a constant expression (pointers to thread_local
// objects aren't really a problem).
//
// X86: @_ZN25thread_local_global_array1xE = thread_local global
// X86: @_ZGRN25thread_local_global_array1xE_ = internal thread_local constant [4 x i32] [i32 1, i32 2, i32 3, i32 4]
std::initializer_list<int> thread_local x = {1, 2, 3, 4};
CodeGen support for function-local static thread_local variables with non-constant constructors or non-trivial destructors. Plus bugfixes for thread_local references bound to temporaries (the temporaries themselves are lifetime-extended to become thread_local), and the corresponding case for std::initializer_list. llvm-svn: 179496
2013-04-15 07:01:42 +08:00
}
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
#endif
// X86: @globalInitList2 = global %{{[^ ]+}} zeroinitializer
// X86: @_ZGR15globalInitList2_ = internal global [2 x %[[WITHARG:[^ ]*]]] zeroinitializer
Clean up AMDGCN tests Differential Revision: https://reviews.llvm.org/D43340 llvm-svn: 325279
2018-02-16 03:12:41 +08:00
// AMDGCN: @globalInitList2 = addrspace(1) global %{{[^ ]+}} zeroinitializer
// AMDGCN: @_ZGR15globalInitList2_ = internal addrspace(1) global [2 x %[[WITHARG:[^ ]*]]] zeroinitializer
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// X86: @_ZN15partly_constant1kE = global i32 0, align 4
// X86: @_ZN15partly_constant2ilE = global {{.*}} null, align 8
Fold dangling-field warning into general initialization lifetime checks. This reinstates r337627, reverted in r337671, with a fix to correctly handle the lvalueness of array subscript expressions on pointers. llvm-svn: 337726
2018-07-24 02:50:26 +08:00
// X86: @[[PARTLY_CONSTANT_OUTER:_ZGRN15partly_constant2ilE_]] = internal global {{.*}} zeroinitializer, align 8
// X86: @[[PARTLY_CONSTANT_INNER:_ZGRN15partly_constant2ilE0_]] = internal global [3 x {{.*}}] zeroinitializer, align 8
// X86: @[[PARTLY_CONSTANT_FIRST:_ZGRN15partly_constant2ilE1_]] = internal constant [3 x i32] [i32 1, i32 2, i32 3], align 4
// X86: @[[PARTLY_CONSTANT_SECOND:_ZGRN15partly_constant2ilE2_]] = internal global [2 x i32] zeroinitializer, align 4
// X86: @[[PARTLY_CONSTANT_THIRD:_ZGRN15partly_constant2ilE3_]] = internal constant [4 x i32] [i32 5, i32 6, i32 7, i32 8], align 4
Clean up AMDGCN tests Differential Revision: https://reviews.llvm.org/D43340 llvm-svn: 325279
2018-02-16 03:12:41 +08:00
// AMDGCN: @_ZN15partly_constant1kE = addrspace(1) global i32 0, align 4
[AMDGPU] Clean up old address space mapping and fix constant address space value Differential Revision: https://reviews.llvm.org/D43911 llvm-svn: 326725
2018-03-06 01:50:10 +08:00
// AMDGCN: @_ZN15partly_constant2ilE = addrspace(4) global {{.*}} null, align 8
Fold dangling-field warning into general initialization lifetime checks. This reinstates r337627, reverted in r337671, with a fix to correctly handle the lvalueness of array subscript expressions on pointers. llvm-svn: 337726
2018-07-24 02:50:26 +08:00
// AMDGCN: @[[PARTLY_CONSTANT_OUTER:_ZGRN15partly_constant2ilE_]] = internal addrspace(4) global {{.*}} zeroinitializer, align 8
// AMDGCN: @[[PARTLY_CONSTANT_INNER:_ZGRN15partly_constant2ilE0_]] = internal addrspace(4) global [3 x {{.*}}] zeroinitializer, align 8
// AMDGCN: @[[PARTLY_CONSTANT_FIRST:_ZGRN15partly_constant2ilE1_]] = internal addrspace(4) constant [3 x i32] [i32 1, i32 2, i32 3], align 4
// AMDGCN: @[[PARTLY_CONSTANT_SECOND:_ZGRN15partly_constant2ilE2_]] = internal addrspace(4) global [2 x i32] zeroinitializer, align 4
// AMDGCN: @[[PARTLY_CONSTANT_THIRD:_ZGRN15partly_constant2ilE3_]] = internal addrspace(4) constant [4 x i32] [i32 5, i32 6, i32 7, i32 8], align 4
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// X86: @[[REFTMP1:.*]] = private constant [2 x i32] [i32 42, i32 43], align 4
// X86: @[[REFTMP2:.*]] = private constant [3 x %{{.*}}] [%{{.*}} { i32 1 }, %{{.*}} { i32 2 }, %{{.*}} { i32 3 }], align 4
[AMDGPU] Clean up old address space mapping and fix constant address space value Differential Revision: https://reviews.llvm.org/D43911 llvm-svn: 326725
2018-03-06 01:50:10 +08:00
// AMDGCN: @[[REFTMP1:.*]] = private addrspace(4) constant [2 x i32] [i32 42, i32 43], align 4
// AMDGCN: @[[REFTMP2:.*]] = private addrspace(4) constant [3 x %{{.*}}] [%{{.*}} { i32 1 }, %{{.*}} { i32 2 }, %{{.*}} { i32 3 }], align 4
Reapply r231508 "CodeGen: Emit constant temporaries into read-only globals." I disabled putting the new global into the same COMDAT as the function for now. There's a fundamental problem when we inline references to the global but still have the global in a COMDAT linked to the inlined function. Since this is only an optimization there may be other versions of the COMDAT around that are missing the new global and hell breaks loose at link time. I hope the chromium build doesn't break this time :) llvm-svn: 231564
2015-03-07 21:37:13 +08:00
CodeGen support for global variables of type std::initializer_list<X>. This emits a backing array with internal linkage and fills it with data, then has the initializer_list point at the array. Dynamic initialization and global destructors are correctly supported. What doesn't work is nested initializer_lists. I have no idea how to get them to work, either. However, these should be very rare, and so I'll just call it a known bug and declare generalized initializers DONE! llvm-svn: 151457
2012-02-26 04:51:20 +08:00
// CHECK: appending global
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
// thread_local initializer:
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// X86-LABEL: define internal void @__cxx_global_var_init
// X86: store i32* getelementptr inbounds ([4 x i32], [4 x i32]* @_ZGRN25thread_local_global_array1xE_, i64 0, i64 0),
// X86: i32** getelementptr inbounds ({{.*}}, {{.*}}* @_ZN25thread_local_global_array1xE, i32 0, i32 0), align 8
// X86: store i64 4, i64* getelementptr inbounds ({{.*}}, {{.*}}* @_ZN25thread_local_global_array1xE, i32 0, i32 1), align 8
// CHECK-LABEL: define internal void @__cxx_global_var_init
Revert "[CodeGenCXX] Treat 'this' as noalias in constructors" This reverts commit https://reviews.llvm.org/rL344150 which causes MachineOutliner related failures on the ppc64le multistage buildbot. llvm-svn: 344526
2018-10-15 23:43:00 +08:00
// X86: call void @_ZN8witharg1C1ERK10destroyme1(%[[WITHARG]]* getelementptr inbounds ([2 x %[[WITHARG]]], [2 x %[[WITHARG]]]* @_ZGR15globalInitList2_, i{{32|64}} 0, i{{32|64}} 0
// X86: call void @_ZN8witharg1C1ERK10destroyme1(%[[WITHARG]]* getelementptr inbounds ([2 x %[[WITHARG]]], [2 x %[[WITHARG]]]* @_ZGR15globalInitList2_, i{{32|64}} 0, i{{32|64}} 1
// AMDGCN: call void @_ZN8witharg1C1ERK10destroyme1(%[[WITHARG]]* getelementptr inbounds ([2 x %[[WITHARG]]], [2 x %[[WITHARG]]]* addrspacecast ({{[^@]+}} @_ZGR15globalInitList2_ {{[^)]+}}), i{{32|64}} 0, i{{32|64}} 0
// AMDGCN: call void @_ZN8witharg1C1ERK10destroyme1(%[[WITHARG]]* getelementptr inbounds ([2 x %[[WITHARG]]], [2 x %[[WITHARG]]]* addrspacecast ({{[^@]+}} @_ZGR15globalInitList2_ {{[^)]+}}), i{{32|64}} 0, i{{32|64}} 1
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// CHECK: call i32 @__cxa_atexit
// X86: store %[[WITHARG]]* getelementptr inbounds ([2 x %[[WITHARG]]], [2 x %[[WITHARG]]]* @_ZGR15globalInitList2_, i64 0, i64 0),
// X86: %[[WITHARG]]** getelementptr inbounds (%{{.*}}, %{{.*}}* @globalInitList2, i32 0, i32 0), align 8
// X86: store i64 2, i64* getelementptr inbounds (%{{.*}}, %{{.*}}* @globalInitList2, i32 0, i32 1), align 8
Clean up AMDGCN tests Differential Revision: https://reviews.llvm.org/D43340 llvm-svn: 325279
2018-02-16 03:12:41 +08:00
// AMDGCN: store %[[WITHARG]]* getelementptr inbounds ([2 x %[[WITHARG]]], [2 x %[[WITHARG]]]* addrspacecast ({{[^@]+}} @_ZGR15globalInitList2_ {{[^)]+}}), i64 0, i64 0),
// AMDGCN: %[[WITHARG]]** getelementptr inbounds (%{{.*}}, %{{.*}}* addrspacecast ({{[^@]+}} @globalInitList2 {{[^)]+}}), i32 0, i32 0), align 8
// AMDGCN: store i64 2, i64* getelementptr inbounds (%{{.*}}, %{{.*}}* addrspacecast ({{[^@]+}} @globalInitList2 {{[^)]+}}), i32 0, i32 1), align 8
CodeGen support for global variables of type std::initializer_list<X>. This emits a backing array with internal linkage and fills it with data, then has the initializer_list point at the array. Dynamic initialization and global destructors are correctly supported. What doesn't work is nested initializer_lists. I have no idea how to get them to work, either. However, these should be very rare, and so I'll just call it a known bug and declare generalized initializers DONE! llvm-svn: 151457
2012-02-26 04:51:20 +08:00
// CHECK: call void @_ZN10destroyme1D1Ev
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// CHECK-NEXT: call void @_ZN10destroyme1D1Ev
// CHECK-NEXT: ret void
CodeGen support for global variables of type std::initializer_list<X>. This emits a backing array with internal linkage and fills it with data, then has the initializer_list point at the array. Dynamic initialization and global destructors are correctly supported. What doesn't work is nested initializer_lists. I have no idea how to get them to work, either. However, these should be very rare, and so I'll just call it a known bug and declare generalized initializers DONE! llvm-svn: 151457
2012-02-26 04:51:20 +08:00
std::initializer_list<witharg1> globalInitList2 = {
witharg1(destroyme1()), witharg1(destroyme1())
};
Basic code generation support for std::initializer_list. We now generate temporary arrays to back std::initializer_list objects initialized with braces. The initializer_list is then made to point at the array. We support both ptr+size and start+end forms, although the latter is untested. Array lifetime is correct for temporary std::initializer_lists (e.g. call arguments) and local variables. It is untested for new expressions and member initializers. Things left to do: Massively increase the amount of testing. I need to write tests for start+end init lists, temporary objects created as a side effect of initializing init list objects, new expressions, member initialization, creation of temporary objects (e.g. std::vector) for initializer lists, and probably more. Get lifetime "right" for member initializers and new expressions. Not that either are very useful. Implement list-initialization of array new expressions. llvm-svn: 150803
2012-02-17 16:42:25 +08:00
void fn1(int i) {
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK-LABEL: define void @_Z3fn1i
Basic code generation support for std::initializer_list. We now generate temporary arrays to back std::initializer_list objects initialized with braces. The initializer_list is then made to point at the array. We support both ptr+size and start+end forms, although the latter is untested. Array lifetime is correct for temporary std::initializer_lists (e.g. call arguments) and local variables. It is untested for new expressions and member initializers. Things left to do: Massively increase the amount of testing. I need to write tests for start+end init lists, temporary objects created as a side effect of initializing init list objects, new expressions, member initialization, creation of temporary objects (e.g. std::vector) for initializer lists, and probably more. Get lifetime "right" for member initializers and new expressions. Not that either are very useful. Implement list-initialization of array new expressions. llvm-svn: 150803
2012-02-17 16:42:25 +08:00
// temporary array
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// X86: [[array:%[^ ]+]] = alloca [3 x i32]
Clean up AMDGCN tests Differential Revision: https://reviews.llvm.org/D43340 llvm-svn: 325279
2018-02-16 03:12:41 +08:00
// AMDGCN: [[alloca:%[^ ]+]] = alloca [3 x i32], align 4, addrspace(5)
// AMDGCN: [[array:%[^ ]+]] = addrspacecast [3 x i32] addrspace(5)* [[alloca]] to [3 x i32]*
Update Clang tests to handle explicitly typed gep changes in LLVM. llvm-svn: 230783
2015-02-28 03:18:17 +08:00
// CHECK: getelementptr inbounds [3 x i32], [3 x i32]* [[array]], i{{32|64}} 0
Basic code generation support for std::initializer_list. We now generate temporary arrays to back std::initializer_list objects initialized with braces. The initializer_list is then made to point at the array. We support both ptr+size and start+end forms, although the latter is untested. Array lifetime is correct for temporary std::initializer_lists (e.g. call arguments) and local variables. It is untested for new expressions and member initializers. Things left to do: Massively increase the amount of testing. I need to write tests for start+end init lists, temporary objects created as a side effect of initializing init list objects, new expressions, member initialization, creation of temporary objects (e.g. std::vector) for initializer lists, and probably more. Get lifetime "right" for member initializers and new expressions. Not that either are very useful. Implement list-initialization of array new expressions. llvm-svn: 150803
2012-02-17 16:42:25 +08:00
// CHECK-NEXT: store i32 1, i32*
// CHECK-NEXT: getelementptr
// CHECK-NEXT: store
// CHECK-NEXT: getelementptr
// CHECK-NEXT: load
// CHECK-NEXT: store
// init the list
// CHECK-NEXT: getelementptr
Update Clang tests to handle explicitly typed gep changes in LLVM. llvm-svn: 230783
2015-02-28 03:18:17 +08:00
// CHECK-NEXT: getelementptr inbounds [3 x i32], [3 x i32]*
Basic code generation support for std::initializer_list. We now generate temporary arrays to back std::initializer_list objects initialized with braces. The initializer_list is then made to point at the array. We support both ptr+size and start+end forms, although the latter is untested. Array lifetime is correct for temporary std::initializer_lists (e.g. call arguments) and local variables. It is untested for new expressions and member initializers. Things left to do: Massively increase the amount of testing. I need to write tests for start+end init lists, temporary objects created as a side effect of initializing init list objects, new expressions, member initialization, creation of temporary objects (e.g. std::vector) for initializer lists, and probably more. Get lifetime "right" for member initializers and new expressions. Not that either are very useful. Implement list-initialization of array new expressions. llvm-svn: 150803
2012-02-17 16:42:25 +08:00
// CHECK-NEXT: store i32*
// CHECK-NEXT: getelementptr
// CHECK-NEXT: store i{{32|64}} 3
std::initializer_list<int> intlist{1, 2, i};
}
void fn2() {
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK-LABEL: define void @_Z3fn2v
Basic code generation support for std::initializer_list. We now generate temporary arrays to back std::initializer_list objects initialized with braces. The initializer_list is then made to point at the array. We support both ptr+size and start+end forms, although the latter is untested. Array lifetime is correct for temporary std::initializer_lists (e.g. call arguments) and local variables. It is untested for new expressions and member initializers. Things left to do: Massively increase the amount of testing. I need to write tests for start+end init lists, temporary objects created as a side effect of initializing init list objects, new expressions, member initialization, creation of temporary objects (e.g. std::vector) for initializer lists, and probably more. Get lifetime "right" for member initializers and new expressions. Not that either are very useful. Implement list-initialization of array new expressions. llvm-svn: 150803
2012-02-17 16:42:25 +08:00
void target(std::initializer_list<destroyme1>);
// objects should be destroyed before dm2, after call returns
Add a testcase to show that temporaries from the initializer list are destroyed correctly. llvm-svn: 150924
2012-02-19 20:27:51 +08:00
// CHECK: call void @_Z6targetSt16initializer_listI10destroyme1E
Basic code generation support for std::initializer_list. We now generate temporary arrays to back std::initializer_list objects initialized with braces. The initializer_list is then made to point at the array. We support both ptr+size and start+end forms, although the latter is untested. Array lifetime is correct for temporary std::initializer_lists (e.g. call arguments) and local variables. It is untested for new expressions and member initializers. Things left to do: Massively increase the amount of testing. I need to write tests for start+end init lists, temporary objects created as a side effect of initializing init list objects, new expressions, member initialization, creation of temporary objects (e.g. std::vector) for initializer lists, and probably more. Get lifetime "right" for member initializers and new expressions. Not that either are very useful. Implement list-initialization of array new expressions. llvm-svn: 150803
2012-02-17 16:42:25 +08:00
target({ destroyme1(), destroyme1() });
// CHECK: call void @_ZN10destroyme1D1Ev
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
}
void fn3() {
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK-LABEL: define void @_Z3fn3v
Basic code generation support for std::initializer_list. We now generate temporary arrays to back std::initializer_list objects initialized with braces. The initializer_list is then made to point at the array. We support both ptr+size and start+end forms, although the latter is untested. Array lifetime is correct for temporary std::initializer_lists (e.g. call arguments) and local variables. It is untested for new expressions and member initializers. Things left to do: Massively increase the amount of testing. I need to write tests for start+end init lists, temporary objects created as a side effect of initializing init list objects, new expressions, member initialization, creation of temporary objects (e.g. std::vector) for initializer lists, and probably more. Get lifetime "right" for member initializers and new expressions. Not that either are very useful. Implement list-initialization of array new expressions. llvm-svn: 150803
2012-02-17 16:42:25 +08:00
// objects should be destroyed after dm2
auto list = { destroyme1(), destroyme1() };
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
// CHECK: call void @_ZN10destroyme1D1Ev
}
Add a testcase to show that temporaries from the initializer list are destroyed correctly. llvm-svn: 150924
2012-02-19 20:27:51 +08:00
void fn4() {
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK-LABEL: define void @_Z3fn4v
Add a testcase to show that temporaries from the initializer list are destroyed correctly. llvm-svn: 150924
2012-02-19 20:27:51 +08:00
void target(std::initializer_list<witharg1>);
// objects should be destroyed before dm2, after call returns
// CHECK: call void @_ZN8witharg1C1ERK10destroyme1
// CHECK: call void @_Z6targetSt16initializer_listI8witharg1E
target({ witharg1(destroyme1()), witharg1(destroyme1()) });
// CHECK: call void @_ZN8witharg1D1Ev
// CHECK: call void @_ZN10destroyme1D1Ev
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
}
void fn5() {
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK-LABEL: define void @_Z3fn5v
Add a testcase to show that temporaries from the initializer list are destroyed correctly. llvm-svn: 150924
2012-02-19 20:27:51 +08:00
// temps should be destroyed before dm2
// objects should be destroyed after dm2
// CHECK: call void @_ZN8witharg1C1ERK10destroyme1
auto list = { witharg1(destroyme1()), witharg1(destroyme1()) };
// CHECK: call void @_ZN10destroyme1D1Ev
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
// CHECK: call void @_ZN8witharg1D1Ev
}
Add a testcase for using objects with list-constructors, and fix a Sema crash by repeating an old hack. llvm-svn: 150925
2012-02-19 20:27:56 +08:00
void fn6() {
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK-LABEL: define void @_Z3fn6v
Add a testcase for using objects with list-constructors, and fix a Sema crash by repeating an old hack. llvm-svn: 150925
2012-02-19 20:27:56 +08:00
void target(const wantslist1&);
// objects should be destroyed before dm2, after call returns
// CHECK: call void @_ZN10wantslist1C1ESt16initializer_listI10destroyme1E
// CHECK: call void @_Z6targetRK10wantslist1
target({ destroyme1(), destroyme1() });
// CHECK: call void @_ZN10wantslist1D1Ev
// CHECK: call void @_ZN10destroyme1D1Ev
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
}
void fn7() {
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK-LABEL: define void @_Z3fn7v
Add a testcase for using objects with list-constructors, and fix a Sema crash by repeating an old hack. llvm-svn: 150925
2012-02-19 20:27:56 +08:00
// temps should be destroyed before dm2
// object should be destroyed after dm2
// CHECK: call void @_ZN10wantslist1C1ESt16initializer_listI10destroyme1E
wantslist1 wl = { destroyme1(), destroyme1() };
// CHECK: call void @_ZN10destroyme1D1Ev
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
// CHECK: call void @_ZN10wantslist1D1Ev
}
Get recursive initializer lists to work and add a test. Codegen of std::initializer_list is now complete. Onward to array new. llvm-svn: 150926
2012-02-19 20:28:02 +08:00
void fn8() {
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK-LABEL: define void @_Z3fn8v
Get recursive initializer lists to work and add a test. Codegen of std::initializer_list is now complete. Onward to array new. llvm-svn: 150926
2012-02-19 20:28:02 +08:00
void target(std::initializer_list<std::initializer_list<destroyme1>>);
// objects should be destroyed before dm2, after call returns
// CHECK: call void @_Z6targetSt16initializer_listIS_I10destroyme1EE
std::initializer_list<destroyme1> inner;
target({ inner, { destroyme1() } });
// CHECK: call void @_ZN10destroyme1D1Ev
// Only one destroy loop, since only one inner init list is directly inited.
// CHECK-NOT: call void @_ZN10destroyme1D1Ev
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
}
void fn9() {
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK-LABEL: define void @_Z3fn9v
Get recursive initializer lists to work and add a test. Codegen of std::initializer_list is now complete. Onward to array new. llvm-svn: 150926
2012-02-19 20:28:02 +08:00
// objects should be destroyed after dm2
std::initializer_list<destroyme1> inner;
std::initializer_list<std::initializer_list<destroyme1>> list =
{ inner, { destroyme1() } };
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
// CHECK: call void @_ZN10destroyme1D1Ev
// Only one destroy loop, since only one inner init list is directly inited.
// CHECK-NOT: call void @_ZN10destroyme1D1Ev
// CHECK: ret void
}
Make std::initializer_list member initializers 'work'. llvm-svn: 150930
2012-02-19 23:41:54 +08:00
Reapply r231508 "CodeGen: Emit constant temporaries into read-only globals." I disabled putting the new global into the same COMDAT as the function for now. There's a fundamental problem when we inline references to the global but still have the global in a COMDAT linked to the inlined function. Since this is only an optimization there may be other versions of the COMDAT around that are missing the new global and hell breaks loose at link time. I hope the chromium build doesn't break this time :) llvm-svn: 231564
2015-03-07 21:37:13 +08:00
void fn10(int i) {
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK-LABEL: define void @_Z4fn10i
Make heap-allocation of std::initializer_list 'work'. llvm-svn: 150931
2012-02-20 00:03:09 +08:00
// CHECK: alloca [3 x i32]
[clang] Annotating C++'s `operator new` with more attributes Summary: Right now we annotate C++'s `operator new` with `noalias` attribute, which very much is healthy for optimizations. However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]], there are more promises on global `operator new`, namely: * non-`std::nothrow_t` `operator new` *never* returns `nullptr` * If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned * ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that. Supplying this information may not cause immediate landslide effects on any specific benchmarks, but it for sure will be healthy for optimizer in the sense that the IR will better reflect the guarantees provided in the source code. The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias` attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes? The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`. But while it is okay to add `noalias` metadata in backend, we really should be adding at least the alignment metadata to the AST, since that allows us to perform sema checks on it. Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith Reviewed By: rsmith Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
// CHECK-X86: call noalias nonnull align 16 i8* @_Znw{{[jm]}}
// CHECK-AMDGPU: call noalias nonnull align 8 i8* @_Znw{{[jm]}}
Reapply r231508 "CodeGen: Emit constant temporaries into read-only globals." I disabled putting the new global into the same COMDAT as the function for now. There's a fundamental problem when we inline references to the global but still have the global in a COMDAT linked to the inlined function. Since this is only an optimization there may be other versions of the COMDAT around that are missing the new global and hell breaks loose at link time. I hope the chromium build doesn't break this time :) llvm-svn: 231564
2015-03-07 21:37:13 +08:00
// CHECK: store i32 %
Make heap-allocation of std::initializer_list 'work'. llvm-svn: 150931
2012-02-20 00:03:09 +08:00
// CHECK: store i32 2
// CHECK: store i32 3
// CHECK: store i32*
Reapply r231508 "CodeGen: Emit constant temporaries into read-only globals." I disabled putting the new global into the same COMDAT as the function for now. There's a fundamental problem when we inline references to the global but still have the global in a COMDAT linked to the inlined function. Since this is only an optimization there may be other versions of the COMDAT around that are missing the new global and hell breaks loose at link time. I hope the chromium build doesn't break this time :) llvm-svn: 231564
2015-03-07 21:37:13 +08:00
(void) new std::initializer_list<int> {i, 2, 3};
Make heap-allocation of std::initializer_list 'work'. llvm-svn: 150931
2012-02-20 00:03:09 +08:00
}
void fn11() {
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK-LABEL: define void @_Z4fn11v
Make heap-allocation of std::initializer_list 'work'. llvm-svn: 150931
2012-02-20 00:03:09 +08:00
(void) new std::initializer_list<destroyme1> {destroyme1(), destroyme1()};
// CHECK: call void @_ZN10destroyme1D1Ev
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
}
If the element type of an initializer list has a destructor, make sure we check it. Fixes PR12178. llvm-svn: 152048
2012-03-06 03:35:43 +08:00
namespace PR12178 {
struct string {
string(int);
~string();
};
struct pair {
string a;
int b;
};
struct map {
map(std::initializer_list<pair>);
};
map m{ {1, 2}, {3, 4} };
}
<rdar://problem/13325066> Destroy std::initializer_list temporaries whose lifetime has been extended by reference binding. llvm-svn: 178939
2013-04-06 08:46:20 +08:00
namespace rdar13325066 {
struct X { ~X(); };
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK-LABEL: define void @_ZN12rdar133250664loopERNS_1XES1_
<rdar://problem/13325066> Destroy std::initializer_list temporaries whose lifetime has been extended by reference binding. llvm-svn: 178939
2013-04-06 08:46:20 +08:00
void loop(X &x1, X &x2) {
// CHECK: br label
// CHECK: br i1
// CHECK: br label
Add a bunch of missing "CHECK" colons in tests. NFC. llvm-svn: 232237
2015-03-14 09:10:19 +08:00
// CHECK: call void @_ZN12rdar133250661XD1Ev
<rdar://problem/13325066> Destroy std::initializer_list temporaries whose lifetime has been extended by reference binding. llvm-svn: 178939
2013-04-06 08:46:20 +08:00
// CHECK: br label
// CHECK: br label
// CHECK: call void @_ZN12rdar133250661XD1Ev
// CHECK: br i1
// CHECK: br label
// CHECK: ret void
for (X x : { x1, x2 }) { }
}
}
Fix assert on temporary std::initializer_list. llvm-svn: 182615
2013-05-24 05:54:14 +08:00
namespace dtors {
struct S {
S();
~S();
};
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
void z();
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK-LABEL: define void @_ZN5dtors1fEv(
Fix assert on temporary std::initializer_list. llvm-svn: 182615
2013-05-24 05:54:14 +08:00
void f() {
Clean up test to appease NDEBUG builds. llvm-svn: 183924
2013-06-14 02:07:12 +08:00
// CHECK: call void @_ZN5dtors1SC1Ev(
// CHECK: call void @_ZN5dtors1SC1Ev(
Fix assert on temporary std::initializer_list. llvm-svn: 182615
2013-05-24 05:54:14 +08:00
std::initializer_list<S>{ S(), S() };
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
// Destruction loop for underlying array.
// CHECK: br label
// CHECK: call void @_ZN5dtors1SD1Ev(
// CHECK: br i1
// CHECK: call void @_ZN5dtors1zEv(
z();
// CHECK-NOT: call void @_ZN5dtors1SD1Ev(
Fix assert on temporary std::initializer_list. llvm-svn: 182615
2013-05-24 05:54:14 +08:00
}
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK-LABEL: define void @_ZN5dtors1gEv(
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
void g() {
Clean up test to appease NDEBUG builds. llvm-svn: 183924
2013-06-14 02:07:12 +08:00
// CHECK: call void @_ZN5dtors1SC1Ev(
// CHECK: call void @_ZN5dtors1SC1Ev(
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
auto x = std::initializer_list<S>{ S(), S() };
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
// Destruction loop for underlying array.
// CHECK: br label
// CHECK: call void @_ZN5dtors1SD1Ev(
// CHECK: br i1
// CHECK: call void @_ZN5dtors1zEv(
z();
// CHECK-NOT: call void @_ZN5dtors1SD1Ev(
}
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK-LABEL: define void @_ZN5dtors1hEv(
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
void h() {
Clean up test to appease NDEBUG builds. llvm-svn: 183924
2013-06-14 02:07:12 +08:00
// CHECK: call void @_ZN5dtors1SC1Ev(
// CHECK: call void @_ZN5dtors1SC1Ev(
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
std::initializer_list<S> x = { S(), S() };
// CHECK-NOT: call void @_ZN5dtors1SD1Ev(
// CHECK: call void @_ZN5dtors1zEv(
z();
// Destruction loop for underlying array.
// CHECK: br label
// CHECK: call void @_ZN5dtors1SD1Ev(
// CHECK: br i1
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
}
Fix assert on temporary std::initializer_list. llvm-svn: 182615
2013-05-24 05:54:14 +08:00
}
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
namespace partly_constant {
int k;
std::initializer_list<std::initializer_list<int>> &&il = { { 1, 2, 3 }, { 4, k }, { 5, 6, 7, 8 } };
// First init list.
// CHECK-NOT: @[[PARTLY_CONSTANT_FIRST]],
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// CHECK: store i32* getelementptr inbounds ({{.*}}, {{.*}}* {{.*}}@[[PARTLY_CONSTANT_FIRST]]{{.*}}, i64 0, i64 0),
// CHECK: i32** getelementptr inbounds ({{.*}}, {{.*}}* {{.*}}@[[PARTLY_CONSTANT_INNER]]{{.*}}, i64 0, i64 0, i32 0)
// CHECK: store i64 3, i64* getelementptr inbounds ({{.*}}, {{.*}}* {{.*}}@[[PARTLY_CONSTANT_INNER]]{{.*}}, i64 0, i64 0, i32 1)
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
// CHECK-NOT: @[[PARTLY_CONSTANT_FIRST]],
//
// Second init list array (non-constant).
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// CHECK: store i32 4, i32* getelementptr inbounds ({{.*}}, {{.*}}* {{.*}}@[[PARTLY_CONSTANT_SECOND]]{{.*}}, i64 0, i64 0)
// CHECK: load i32, i32* {{.*}}@_ZN15partly_constant1kE
// CHECK: store i32 {{.*}}, i32* getelementptr inbounds ({{.*}}, {{.*}}* {{.*}}@[[PARTLY_CONSTANT_SECOND]]{{.*}}, i64 0, i64 1)
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
//
// Second init list.
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// CHECK: store i32* getelementptr inbounds ({{.*}}, {{.*}}* {{.*}}@[[PARTLY_CONSTANT_SECOND]]{{.*}}, i64 0, i64 0),
// CHECK: i32** getelementptr inbounds ({{.*}}, {{.*}}* {{.*}}@[[PARTLY_CONSTANT_INNER]]{{.*}}, i64 0, i64 1, i32 0)
// CHECK: store i64 2, i64* getelementptr inbounds ({{.*}}, {{.*}}* {{.*}}@[[PARTLY_CONSTANT_INNER]]{{.*}}, i64 0, i64 1, i32 1)
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
//
// Third init list.
// CHECK-NOT: @[[PARTLY_CONSTANT_THIRD]],
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// CHECK: store i32* getelementptr inbounds ({{.*}}, {{.*}}* {{.*}}@[[PARTLY_CONSTANT_THIRD]]{{.*}}, i64 0, i64 0),
// CHECK: i32** getelementptr inbounds ({{.*}}, {{.*}}* {{.*}}@[[PARTLY_CONSTANT_INNER]]{{.*}}, i64 0, i64 2, i32 0)
Fold dangling-field warning into general initialization lifetime checks. This reinstates r337627, reverted in r337671, with a fix to correctly handle the lvalueness of array subscript expressions on pointers. llvm-svn: 337726
2018-07-24 02:50:26 +08:00
// CHECK: store i64 4, i64* getelementptr inbounds ({{.*}}, {{.*}}* {{.*}}@[[PARTLY_CONSTANT_INNER]]{{.*}}, i64 0, i64 2, i32 1)
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
// CHECK-NOT: @[[PARTLY_CONSTANT_THIRD]],
//
// Outer init list.
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// CHECK: store {{.*}}* getelementptr inbounds ({{.*}}, {{.*}}* {{.*}}@[[PARTLY_CONSTANT_INNER]]{{.*}}, i64 0, i64 0),
// CHECK: {{.*}}** getelementptr inbounds ({{.*}}, {{.*}}* {{.*}}@[[PARTLY_CONSTANT_OUTER]]{{.*}}, i32 0, i32 0)
// CHECK: store i64 3, i64* getelementptr inbounds ({{.*}}, {{.*}}* {{.*}}@[[PARTLY_CONSTANT_OUTER]]{{.*}}, i32 0, i32 1)
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
//
// 'il' reference.
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// CHECK: store {{.*}}* {{.*}}@[[PARTLY_CONSTANT_OUTER]]{{.*}}, {{.*}}** {{.*}}@_ZN15partly_constant2ilE{{.*}}, align 8
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
}
Fix nested lifetime extension when a std::initializer_list member is initialized during aggregate initialization of the surrounding structure. llvm-svn: 185117
2013-06-28 06:54:33 +08:00
namespace nested {
struct A { A(); ~A(); };
struct B { const A &a; ~B(); };
struct C { std::initializer_list<B> b; ~C(); };
void f();
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK-LABEL: define void @_ZN6nested1gEv(
Fix nested lifetime extension when a std::initializer_list member is initialized during aggregate initialization of the surrounding structure. llvm-svn: 185117
2013-06-28 06:54:33 +08:00
void g() {
// CHECK: call void @_ZN6nested1AC1Ev(
// CHECK-NOT: call
// CHECK: call void @_ZN6nested1AC1Ev(
// CHECK-NOT: call
const C &c { { { A() }, { A() } } };
// CHECK: call void @_ZN6nested1fEv(
// CHECK-NOT: call
f();
// CHECK: call void @_ZN6nested1CD1Ev(
// CHECK-NOT: call
// Destroy B[2] array.
// FIXME: This isn't technically correct: reverse construction order would
// destroy the second B then the second A then the first B then the first A.
// CHECK: call void @_ZN6nested1BD1Ev(
// CHECK-NOT: call
// CHECK: br
// CHECK-NOT: call
// CHECK: call void @_ZN6nested1AD1Ev(
// CHECK-NOT: call
// CHECK: call void @_ZN6nested1AD1Ev(
// CHECK-NOT: call
// CHECK: }
}
}
Implement DR990 and DR1070. Aggregate initialization initializes uninitialized elements from {}, rather than value-initializing them. This permits calling an initializer-list constructor or constructing a std::initializer_list object. (It would also permit initializing a const reference or rvalue reference if that weren't explicitly prohibited by other rules.) llvm-svn: 210091
2014-06-03 16:26:00 +08:00
namespace DR1070 {
struct A {
A(std::initializer_list<int>);
};
struct B {
int i;
A a;
};
B b = {1};
struct C {
std::initializer_list<int> a;
B b;
std::initializer_list<double> c;
};
C c = {};
}
Remove incorrect assertion. llvm-svn: 210092
2014-06-03 16:40:27 +08:00
namespace ArrayOfInitList {
struct S {
S(std::initializer_list<int>);
};
S x[1] = {};
}
PR20445: Properly transform the initializer in a CXXNewExpr rather than running it through the normal TreeTransform logic for Exprs (which will strip off implicit parts of the initialization and never re-create them). llvm-svn: 213913
2014-07-25 09:12:44 +08:00
namespace PR20445 {
struct vector { vector(std::initializer_list<int>); };
struct MyClass { explicit MyClass(const vector &v); };
template<int x> void f() { new MyClass({42, 43}); }
template void f<0>();
// CHECK-LABEL: define {{.*}} @_ZN7PR204451fILi0EEEvv(
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// CHECK: store i32* getelementptr inbounds ([2 x i32], [2 x i32]* {{.*}}@[[REFTMP1]]{{.*}}, i64 0, i64 0)
PR20445: Properly transform the initializer in a CXXNewExpr rather than running it through the normal TreeTransform logic for Exprs (which will strip off implicit parts of the initialization and never re-create them). llvm-svn: 213913
2014-07-25 09:12:44 +08:00
// CHECK: call void @_ZN7PR204456vectorC1ESt16initializer_listIiE(
// CHECK: call void @_ZN7PR204457MyClassC1ERKNS_6vectorE(
}
Reapply r231508 "CodeGen: Emit constant temporaries into read-only globals." I disabled putting the new global into the same COMDAT as the function for now. There's a fundamental problem when we inline references to the global but still have the global in a COMDAT linked to the inlined function. Since this is only an optimization there may be other versions of the COMDAT around that are missing the new global and hell breaks loose at link time. I hope the chromium build doesn't break this time :) llvm-svn: 231564
2015-03-07 21:37:13 +08:00
namespace ConstExpr {
class C {
int x;
public:
constexpr C(int x) : x(x) {}
};
void f(std::initializer_list<C>);
void g() {
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// CHECK-LABEL: _ZN9ConstExpr1gEv
// CHECK: store %"class.ConstExpr::C"* getelementptr inbounds ([3 x %"class.ConstExpr::C"], [3 x %"class.ConstExpr::C"]* {{.*}}@[[REFTMP2]]{{.*}}, i64 0, i64 0)
// CHECK: call void @_ZN9ConstExpr1fESt16initializer_listINS_1CEE
Reapply r231508 "CodeGen: Emit constant temporaries into read-only globals." I disabled putting the new global into the same COMDAT as the function for now. There's a fundamental problem when we inline references to the global but still have the global in a COMDAT linked to the inlined function. Since this is only an optimization there may be other versions of the COMDAT around that are missing the new global and hell breaks loose at link time. I hope the chromium build doesn't break this time :) llvm-svn: 231564
2015-03-07 21:37:13 +08:00
f({C(1), C(2), C(3)});
}
}
Fix the LLVM type used when lowering initializer list reference temporaries to global variables. Reapplies r232454 with fix for PR22940. llvm-svn: 232579
2015-03-18 09:06:24 +08:00
namespace B19773010 {
template <class T1, class T2> struct pair {
T1 first;
T2 second;
constexpr pair() : first(), second() {}
constexpr pair(T1 a, T2 b) : first(a), second(b) {}
};
enum E { ENUM_CONSTANT };
struct testcase {
testcase(std::initializer_list<pair<const char *, E>>);
};
void f1() {
// CHECK-LABEL: @_ZN9B197730102f1Ev
testcase a{{"", ENUM_CONSTANT}};
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// X86: store %"struct.B19773010::pair"* getelementptr inbounds ([1 x %"struct.B19773010::pair"], [1 x %"struct.B19773010::pair"]* bitcast ([1 x { i8*, i32 }]* @.ref.tmp{{.*}} to [1 x %"struct.B19773010::pair"]*), i64 0, i64 0), %"struct.B19773010::pair"** %{{.*}}, align 8
[AMDGPU] Clean up old address space mapping and fix constant address space value Differential Revision: https://reviews.llvm.org/D43911 llvm-svn: 326725
2018-03-06 01:50:10 +08:00
// AMDGCN: store %"struct.B19773010::pair"* getelementptr inbounds ([1 x %"struct.B19773010::pair"], [1 x %"struct.B19773010::pair"]* addrspacecast{{.*}} bitcast ([1 x { i8*, i32 }] addrspace(4)* @.ref.tmp{{.*}} to [1 x %"struct.B19773010::pair"] addrspace(4)*){{.*}}, i64 0, i64 0), %"struct.B19773010::pair"** %{{.*}}, align 8
Fix the LLVM type used when lowering initializer list reference temporaries to global variables. Reapplies r232454 with fix for PR22940. llvm-svn: 232579
2015-03-18 09:06:24 +08:00
}
void f2() {
// CHECK-LABEL: @_ZN9B197730102f2Ev
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
// X86: store %"struct.B19773010::pair"* getelementptr inbounds ([1 x %"struct.B19773010::pair"], [1 x %"struct.B19773010::pair"]* bitcast ([1 x { i8*, i32 }]* @_ZGRZN9B197730102f2EvE1p_ to [1 x %"struct.B19773010::pair"]*), i64 0, i64 0), %"struct.B19773010::pair"** getelementptr inbounds ([2 x %"class.std::initializer_list.10"], [2 x %"class.std::initializer_list.10"]* @_ZZN9B197730102f2EvE1p, i64 0, i64 1, i32 0), align 16
Clean up AMDGCN tests Differential Revision: https://reviews.llvm.org/D43340 llvm-svn: 325279
2018-02-16 03:12:41 +08:00
// AMDGCN: store %"struct.B19773010::pair"* getelementptr inbounds ([1 x %"struct.B19773010::pair"], [1 x %"struct.B19773010::pair"]* addrspacecast{{.*}} bitcast ([1 x { i8*, i32 }] addrspace(1)* @_ZGRZN9B197730102f2EvE1p_ to [1 x %"struct.B19773010::pair"] addrspace(1)*){{.*}}, i64 0, i64 0), %"struct.B19773010::pair"** getelementptr inbounds ([2 x %"class.std::initializer_list.10"], [2 x %"class.std::initializer_list.10"]* addrspacecast{{.*}}@_ZZN9B197730102f2EvE1p{{.*}}, i64 0, i64 1, i32 0), align 8
Fix the LLVM type used when lowering initializer list reference temporaries to global variables. Reapplies r232454 with fix for PR22940. llvm-svn: 232579
2015-03-18 09:06:24 +08:00
static std::initializer_list<pair<const char *, E>> a, p[2] =
{a, {{"", ENUM_CONSTANT}}};
}
void PR22940_helper(const pair<void*, int>&) { }
void PR22940() {
// CHECK-LABEL: @_ZN9B197730107PR22940Ev
[CodeGen] Do a more principled fix for PR231653, always use the inner type. We were still using the MaterializeTemporaryExpr's type to check if the transform is legal. Always use the inner Expr type. llvm-svn: 234543
2015-04-10 06:50:07 +08:00
// CHECK: call {{.*}} @_ZN9B197730104pairIPviEC{{.}}Ev(
Fix the LLVM type used when lowering initializer list reference temporaries to global variables. Reapplies r232454 with fix for PR22940. llvm-svn: 232579
2015-03-18 09:06:24 +08:00
// CHECK: call {{.*}} @_ZN9B1977301014PR22940_helperERKNS_4pairIPviEE(
PR22940_helper(pair<void*, int>());
}
}