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/microsoft-abi-static-initia...

252 lines
7.3 KiB
C++
Raw Normal View History

MS ABI: Use a different guard variable for each weak global We were using the same guard variable and failing to initialize the second global. Clang is still not MS ABI compatible in this area. Fixing that is PR16959, which will require LLVM changes to @llvm.global_ctors. llvm-svn: 207008
2014-04-24 02:22:11 +08:00
// RUN: %clang_cc1 -fms-extensions -emit-llvm %s -o - -mconstructor-aliases -triple=i386-pc-win32 | FileCheck %s
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
MS ABI: Emit dynamic initializers for selectany globals in comdat-associative sections (PR20889) This prevents initializers for comdat-folded globals from running multiple times. Differential Revision: http://reviews.llvm.org/D5281 llvm-svn: 217534
2014-09-11 03:28:48 +08:00
// CHECK: @llvm.global_ctors = appending global [5 x { i32, void ()*, i8* }] [
// CHECK: { i32, void ()*, i8* } { i32 65535, void ()* @"\01??__Eselectany1@@YAXXZ", i8* getelementptr inbounds (%struct.S* @"\01?selectany1@@3US@@A", i32 0, i32 0) },
// CHECK: { i32, void ()*, i8* } { i32 65535, void ()* @"\01??__Eselectany2@@YAXXZ", i8* getelementptr inbounds (%struct.S* @"\01?selectany2@@3US@@A", i32 0, i32 0) },
// CHECK: { i32, void ()*, i8* } { i32 65535, void ()* @"\01??__Es@?$ExportedTemplate@H@@2US@@A@YAXXZ", i8* getelementptr inbounds (%struct.S* @"\01?s@?$ExportedTemplate@H@@2US@@A", i32 0, i32 0) },
// CHECK: { i32, void ()*, i8* } { i32 65535, void ()* @"\01??__Efoo@?$B@H@@2VA@@A@YAXXZ", i8* bitcast (%class.A* @"\01?foo@?$B@H@@2VA@@A" to i8*) },
// CHECK: { i32, void ()*, i8* } { i32 65535, void ()* @_GLOBAL__sub_I_microsoft_abi_static_initializers.cpp, i8* null }
// CHECK: ]
Add a separate llvm.global_ctors entry for linkonce_odr data initializers Summary: These typically come from static data members of class template specializations. This accomplishes two things: 1. May expose GlobalOpt optimizations for Itanium C++ ABI code. 2. Works toward fixing double initialization in the Microsoft C++ ABI. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1475 llvm-svn: 189051
2013-08-23 04:07:45 +08:00
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
struct S {
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
S();
~S();
};
S s;
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
// CHECK: define internal void @"\01??__Es@@YAXXZ"()
// CHECK: call x86_thiscallcc %struct.S* @"\01??0S@@QAE@XZ"
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
// CHECK: call i32 @atexit(void ()* @"\01??__Fs@@YAXXZ")
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
// CHECK: ret void
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
// CHECK: define internal void @"\01??__Fs@@YAXXZ"()
[Windows] Use thiscall as the default calling convention for class methods. PR12785 llvm-svn: 160121
2012-07-12 17:50:54 +08:00
// CHECK: call x86_thiscallcc void @"\01??1S@@QAE@XZ"
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
// CHECK: ret void
MS ABI: Emit dynamic initializers for selectany globals in comdat-associative sections (PR20889) This prevents initializers for comdat-folded globals from running multiple times. Differential Revision: http://reviews.llvm.org/D5281 llvm-svn: 217534
2014-09-11 03:28:48 +08:00
// These globals should have initializers comdat associative with the global.
// See @llvm.global_ctors above.
MS ABI: Use a different guard variable for each weak global We were using the same guard variable and failing to initialize the second global. Clang is still not MS ABI compatible in this area. Fixing that is PR16959, which will require LLVM changes to @llvm.global_ctors. llvm-svn: 207008
2014-04-24 02:22:11 +08:00
__declspec(selectany) S selectany1;
__declspec(selectany) S selectany2;
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
// CHECK: define linkonce_odr void @"\01??__Eselectany1@@YAXXZ"()
// CHECK-NOT: @"\01??_Bselectany1
// CHECK: call x86_thiscallcc %struct.S* @"\01??0S@@QAE@XZ"
MS ABI: Use a different guard variable for each weak global We were using the same guard variable and failing to initialize the second global. Clang is still not MS ABI compatible in this area. Fixing that is PR16959, which will require LLVM changes to @llvm.global_ctors. llvm-svn: 207008
2014-04-24 02:22:11 +08:00
// CHECK: ret void
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
// CHECK: define linkonce_odr void @"\01??__Eselectany2@@YAXXZ"()
// CHECK-NOT: @"\01??_Bselectany2
// CHECK: call x86_thiscallcc %struct.S* @"\01??0S@@QAE@XZ"
MS ABI: Use a different guard variable for each weak global We were using the same guard variable and failing to initialize the second global. Clang is still not MS ABI compatible in this area. Fixing that is PR16959, which will require LLVM changes to @llvm.global_ctors. llvm-svn: 207008
2014-04-24 02:22:11 +08:00
// CHECK: ret void
MS ABI: Emit dynamic initializers for selectany globals in comdat-associative sections (PR20889) This prevents initializers for comdat-folded globals from running multiple times. Differential Revision: http://reviews.llvm.org/D5281 llvm-svn: 217534
2014-09-11 03:28:48 +08:00
// The implicitly instantiated static data member should have initializer
// comdat associative with the global.
template <typename T> struct __declspec(dllexport) ExportedTemplate {
static S s;
};
template <typename T> S ExportedTemplate<T>::s;
void useExportedTemplate(ExportedTemplate<int> x) {
(void)x.s;
}
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
void StaticLocal() {
static S TheS;
}
MS ABI: Emit dynamic initializers for selectany globals in comdat-associative sections (PR20889) This prevents initializers for comdat-folded globals from running multiple times. Differential Revision: http://reviews.llvm.org/D5281 llvm-svn: 217534
2014-09-11 03:28:48 +08:00
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
// CHECK-LABEL: define void @"\01?StaticLocal@@YAXXZ"()
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
// CHECK: load i32* @"\01?$S1@?0??StaticLocal@@YAXXZ@4IA"
// CHECK: store i32 {{.*}}, i32* @"\01?$S1@?0??StaticLocal@@YAXXZ@4IA"
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
// CHECK: ret
void MultipleStatics() {
static S S1;
static S S2;
static S S3;
static S S4;
static S S5;
static S S6;
static S S7;
static S S8;
static S S9;
static S S10;
static S S11;
static S S12;
static S S13;
static S S14;
static S S15;
static S S16;
static S S17;
static S S18;
static S S19;
static S S20;
static S S21;
static S S22;
static S S23;
static S S24;
static S S25;
static S S26;
static S S27;
static S S28;
static S S29;
static S S30;
static S S31;
static S S32;
static S S33;
static S S34;
static S S35;
}
// CHECK-LABEL: define void @"\01?MultipleStatics@@YAXXZ"()
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
// CHECK: load i32* @"\01?$S1@?0??MultipleStatics@@YAXXZ@4IA"
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
// CHECK: and i32 {{.*}}, 1
// CHECK: and i32 {{.*}}, 2
// CHECK: and i32 {{.*}}, 4
// CHECK: and i32 {{.*}}, 8
// CHECK: and i32 {{.*}}, 16
// ...
// CHECK: and i32 {{.*}}, -2147483648
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
// CHECK: load i32* @"\01?$S1@?0??MultipleStatics@@YAXXZ@4IA1"
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
// CHECK: and i32 {{.*}}, 1
// CHECK: and i32 {{.*}}, 2
// CHECK: and i32 {{.*}}, 4
// CHECK: ret
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
// Force WeakODRLinkage by using templates
class A {
public:
A() {}
~A() {}
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
int a;
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
};
template<typename T>
class B {
public:
static A foo;
};
template<typename T> A B<T>::foo;
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
inline S &UnreachableStatic() {
if (0) {
static S s; // bit 1
return s;
}
static S s; // bit 2
return s;
}
Mark C++ reference parameters as dereferenceable Because references must be initialized using some evaluated expression, they must point to something, and a callee can assume the reference parameter is dereferenceable. Taking advantage of a new attribute just added to LLVM, mark them as such. Because dereferenceability in addrspace(0) implies nonnull in the backend, we don't need both attributes. However, we need to know the size of the object to use the dereferenceable attribute, so for incomplete types we still emit only nonnull. llvm-svn: 213386
2014-07-18 23:52:10 +08:00
// CHECK-LABEL: define linkonce_odr dereferenceable({{[0-9]+}}) %struct.S* @"\01?UnreachableStatic@@YAAAUS@@XZ"()
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
// CHECK: and i32 {{.*}}, 2
// CHECK: or i32 {{.*}}, 2
// CHECK: ret
inline S &getS() {
static S TheS;
return TheS;
}
Mark C++ reference parameters as dereferenceable Because references must be initialized using some evaluated expression, they must point to something, and a callee can assume the reference parameter is dereferenceable. Taking advantage of a new attribute just added to LLVM, mark them as such. Because dereferenceability in addrspace(0) implies nonnull in the backend, we don't need both attributes. However, we need to know the size of the object to use the dereferenceable attribute, so for incomplete types we still emit only nonnull. llvm-svn: 213386
2014-07-18 23:52:10 +08:00
// CHECK-LABEL: define linkonce_odr dereferenceable({{[0-9]+}}) %struct.S* @"\01?getS@@YAAAUS@@XZ"
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
// CHECK: load i32* @"\01??_B?1??getS@@YAAAUS@@XZ@51"
// CHECK: and i32 {{.*}}, 1
// CHECK: icmp ne i32 {{.*}}, 0
// CHECK: br i1
// init:
// CHECK: or i32 {{.*}}, 1
// CHECK: store i32 {{.*}}, i32* @"\01??_B?1??getS@@YAAAUS@@XZ@51"
// CHECK: call x86_thiscallcc %struct.S* @"\01??0S@@QAE@XZ"(%struct.S* @"\01?TheS@?1??getS@@YAAAUS@@XZ@4U2@A")
// CHECK: call i32 @atexit(void ()* @"\01??__FTheS@?1??getS@@YAAAUS@@XZ@YAXXZ")
// CHECK: br label
// init.end:
// CHECK: ret %struct.S* @"\01?TheS@?1??getS@@YAAAUS@@XZ@4U2@A"
MS static locals mangling: don't count enum scopes We may not have the mangling for static locals vs. enums completely figured out, but at least for my simple test cases, enums should not increment the mangling number. Differential Revision: http://reviews.llvm.org/D4164 llvm-svn: 211078
2014-06-17 08:00:18 +08:00
inline int enum_in_function() {
// CHECK-LABEL: define linkonce_odr i32 @"\01?enum_in_function@@YAHXZ"()
static enum e { foo, bar, baz } x;
// CHECK: @"\01?x@?1??enum_in_function@@YAHXZ@4W4e@?1??1@YAHXZ@A"
static int y;
// CHECK: @"\01?y@?1??enum_in_function@@YAHXZ@4HA"
return x + y;
};
struct T {
enum e { foo, bar, baz };
int enum_in_struct() {
// CHECK-LABEL: define linkonce_odr x86_thiscallcc i32 @"\01?enum_in_struct@T@@QAEHXZ"
static int x;
// CHECK: @"\01?x@?1??enum_in_struct@T@@QAEHXZ@4HA"
return x++;
}
};
MS static locals mangling: don't double-increment mangling number for switches Differential Revision: http://reviews.llvm.org/D4165 llvm-svn: 211079
2014-06-17 08:09:05 +08:00
inline int switch_test(int x) {
// CHECK-LABEL: define linkonce_odr i32 @"\01?switch_test@@YAHH@Z"(i32 %x)
switch (x) {
static int a;
// CHECK: @"\01?a@?3??switch_test@@YAHH@Z@4HA"
case 0:
a++;
return 1;
case 1:
static int b;
// CHECK: @"\01?b@?3??switch_test@@YAHH@Z@4HA"
return b++;
case 2: {
static int c;
// CHECK: @"\01?c@?4??switch_test@@YAHH@Z@4HA"
return b + c++;
}
};
}
int f();
inline void switch_test2() {
// CHECK-LABEL: define linkonce_odr void @"\01?switch_test2@@YAXXZ"()
// CHECK: @"\01?x@?2??switch_test2@@YAXXZ@4HA"
switch (1) default: static int x = f();
}
Fix bug in code for avoiding dynamic initialization of dllimport globals When instantiating dllimport variables with dynamic initializers, don't bail out of Sema::InstantiateVariableInitializer without calling PopExpressionEvaluationContext(). This was causing a stale object to stay on the ExprEvalContexts stack, causing subsequent calls to getCurrentMangleNumberContext() to fail, resulting in incorrect numbering of static locals (and probably other broken things). llvm-svn: 211137
2014-06-18 09:21:33 +08:00
namespace DynamicDLLImportInitVSMangling {
// Failing to pop the ExprEvalContexts when instantiating a dllimport var with
// dynamic initializer would cause subsequent static local numberings to be
// incorrect.
struct NonPOD { NonPOD(); };
template <typename T> struct A { static NonPOD x; };
template <typename T> NonPOD A<T>::x;
template struct __declspec(dllimport) A<int>;
inline int switch_test3() {
// CHECK-LABEL: define linkonce_odr i32 @"\01?switch_test3@DynamicDLLImportInitVSMangling@@YAHXZ"
static int local;
// CHECK: @"\01?local@?1??switch_test3@DynamicDLLImportInitVSMangling@@YAHXZ@4HA"
return local++;
}
}
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
void force_usage() {
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
UnreachableStatic();
getS();
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
(void)B<int>::foo; // (void) - force usage
MS static locals mangling: don't count enum scopes We may not have the mangling for static locals vs. enums completely figured out, but at least for my simple test cases, enums should not increment the mangling number. Differential Revision: http://reviews.llvm.org/D4164 llvm-svn: 211078
2014-06-17 08:00:18 +08:00
enum_in_function();
(void)&T::enum_in_struct;
MS static locals mangling: don't double-increment mangling number for switches Differential Revision: http://reviews.llvm.org/D4165 llvm-svn: 211079
2014-06-17 08:09:05 +08:00
switch_test(1);
switch_test2();
Fix bug in code for avoiding dynamic initialization of dllimport globals When instantiating dllimport variables with dynamic initializers, don't bail out of Sema::InstantiateVariableInitializer without calling PopExpressionEvaluationContext(). This was causing a stale object to stay on the ExprEvalContexts stack, causing subsequent calls to getCurrentMangleNumberContext() to fail, resulting in incorrect numbering of static locals (and probably other broken things). llvm-svn: 211137
2014-06-18 09:21:33 +08:00
DynamicDLLImportInitVSMangling::switch_test3();
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
}
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
// CHECK: define linkonce_odr void @"\01??__Efoo@?$B@H@@2VA@@A@YAXXZ"()
// CHECK-NOT: and
// CHECK-NOT: ?_Bfoo@
// CHECK: call x86_thiscallcc %class.A* @"\01??0A@@QAE@XZ"
MS ABI: Fix the initializer/finalizer mangling for static data members Initializers and finalizers for static data members have the variable's access-specifier, storage-class, type and CV-qualifiers mangled in. llvm-svn: 203145
2014-03-07 03:10:27 +08:00
// CHECK: call i32 @atexit(void ()* @"\01??__Ffoo@?$B@H@@2VA@@A@YAXXZ")
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
// CHECK: ret void
In the MS ABI, ctors return 'this'. Patch by Dmitry Sokolov. llvm-svn: 164592
2012-09-25 16:00:39 +08:00
// CHECK: define linkonce_odr x86_thiscallcc %class.A* @"\01??0A@@QAE@XZ"
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
[Windows] Use thiscall as the default calling convention for class methods. PR12785 llvm-svn: 160121
2012-07-12 17:50:54 +08:00
// CHECK: define linkonce_odr x86_thiscallcc void @"\01??1A@@QAE@XZ"
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
MS ABI: Fix the initializer/finalizer mangling for static data members Initializers and finalizers for static data members have the variable's access-specifier, storage-class, type and CV-qualifiers mangled in. llvm-svn: 203145
2014-03-07 03:10:27 +08:00
// CHECK: define internal void @"\01??__Ffoo@?$B@H@@2VA@@A@YAXXZ"
[Windows] Use thiscall as the default calling convention for class methods. PR12785 llvm-svn: 160121
2012-07-12 17:50:54 +08:00
// CHECK: call x86_thiscallcc void @"\01??1A@@QAE@XZ"{{.*}}foo
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
// CHECK: ret void
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
// CHECK: define internal void @_GLOBAL__sub_I_microsoft_abi_static_initializers.cpp()
[ms-cxxabi] Mangle dynamic initializer stubs the same way MSVC does Summary: Dynamic initializers are mangled as ??__E <name> YAXXZ. Reviewers: timurrrr CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1477 llvm-svn: 190434
2013-09-11 04:43:12 +08:00
// CHECK: call void @"\01??__Es@@YAXXZ"()
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
// CHECK: ret void