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.6 KiB
C++
Raw Normal View History

[MS ABI] Implement thread-safe initialization using the MSVC 2015 ABI The MSVC 2015 ABI utilizes a rather straightforward adaptation of the algorithm found in the appendix of N2382. While we are here, implement support for emitting cleanups if an exception is thrown while we are intitializing a static local variable. llvm-svn: 236697
2015-05-07 14:15:46 +08:00
// RUN: %clang_cc1 -fms-extensions -fno-threadsafe-statics -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* }] [
Test case updates for explicit type parameter to the gep operator llvm-svn: 232187
2015-03-14 02:21:46 +08:00
// CHECK: { i32, void ()*, i8* } { i32 65535, void ()* @"\01??__Eselectany1@@YAXXZ", i8* getelementptr inbounds (%struct.S, %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, %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, %struct.S* @"\01?s@?$ExportedTemplate@H@@2US@@A", i32 0, i32 0) },
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: { 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;
Add comdats to dynamic init functions in the microsoft abi. llvm-svn: 226286
2015-01-17 00:04:45 +08:00
// CHECK: define linkonce_odr void @"\01??__Eselectany1@@YAXXZ"() {{.*}} comdat
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-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
Add comdats to dynamic init functions in the microsoft abi. llvm-svn: 226286
2015-01-17 00:04:45 +08:00
// CHECK: define linkonce_odr void @"\01??__Eselectany2@@YAXXZ"() {{.*}} comdat
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-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"()
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK: load i32, i32* @"\01?$S1@?1??StaticLocal@@YAXXZ@4IA"
MS ABI: Use '1' (instead of '0') relative scope discriminators This changes the scope discriminator's behavior to start at '1' instead of '0'. Symbol table diffing, for ABI compatibility testing, kept finding these as false positives. llvm-svn: 219075
2014-10-05 14:44:53 +08:00
// CHECK: store i32 {{.*}}, i32* @"\01?$S1@?1??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"()
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK: load i32, i32* @"\01?$S1@?1??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
Changed renaming of local symbols by inserting a dot vefore the numeric suffix details in http://reviews.llvm.org/D9483 goes with llvm checkin r237150 llvm-svn: 237151
2015-05-13 00:48:43 +08:00
// CHECK: load i32, i32* @"\01?$S1@?1??MultipleStatics@@YAXXZ@4IA.1"
[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;
}
Make this test a bit stricter. NFC. llvm-svn: 226285
2015-01-17 00:02:03 +08:00
// CHECK-LABEL: define linkonce_odr dereferenceable({{[0-9]+}}) %struct.S* @"\01?UnreachableStatic@@YAAAUS@@XZ"() {{.*}} comdat
[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;
}
Make this test a bit stricter. NFC. llvm-svn: 226285
2015-01-17 00:02:03 +08:00
// CHECK-LABEL: define linkonce_odr dereferenceable({{[0-9]+}}) %struct.S* @"\01?getS@@YAAAUS@@XZ"() {{.*}} comdat
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK: load i32, i32* @"\01??_B?1??getS@@YAAAUS@@XZ@51"
[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
Add branch weights to branches for static initializers. The initializer for a static local variable cannot be hot, because it runs at most once per program. That's not quite the same thing as having a low branch probability, but under the assumption that the function is invoked many times, modeling this as a branch probability seems reasonable. For TLS variables, the situation is less clear, since the initialization side of the branch can run multiple times in a program execution, but we still expect initialization to be rare relative to non-initialization uses. It would seem worthwhile to add a PGO counter along this path to make this estimation more accurate in future. For globals with guarded initialization, we don't yet apply any branch weights. Due to our use of COMDATs, the guard will be reached exactly once per DSO, but we have no idea how many DSOs will define the variable. llvm-svn: 309195
2017-07-27 06:01:09 +08:00
// CHECK: icmp eq i32 {{.*}}, 0
[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: 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() {
Make this test a bit stricter. NFC. llvm-svn: 226285
2015-01-17 00:02:03 +08:00
// CHECK-LABEL: define linkonce_odr i32 @"\01?enum_in_function@@YAHXZ"() {{.*}} comdat
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
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() {
Make this test a bit stricter. NFC. llvm-svn: 226285
2015-01-17 00:02:03 +08:00
// CHECK-LABEL: define linkonce_odr x86_thiscallcc i32 @"\01?enum_in_struct@T@@QAEHXZ"({{.*}}) {{.*}} comdat
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
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) {
Make this test a bit stricter. NFC. llvm-svn: 226285
2015-01-17 00:02:03 +08:00
// CHECK-LABEL: define linkonce_odr i32 @"\01?switch_test@@YAHH@Z"(i32 %x) {{.*}} comdat
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 (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() {
Make this test a bit stricter. NFC. llvm-svn: 226285
2015-01-17 00:02:03 +08:00
// CHECK-LABEL: define linkonce_odr void @"\01?switch_test2@@YAXXZ"() {{.*}} comdat
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
// 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() {
Make this test a bit stricter. NFC. llvm-svn: 226285
2015-01-17 00:02:03 +08:00
// CHECK-LABEL: define linkonce_odr i32 @"\01?switch_test3@DynamicDLLImportInitVSMangling@@YAHXZ"() {{.*}} comdat
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
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
}
Add comdats to dynamic init functions in the microsoft abi. llvm-svn: 226286
2015-01-17 00:04:45 +08:00
// CHECK: define linkonce_odr void @"\01??__Efoo@?$B@H@@2VA@@A@YAXXZ"() {{.*}} comdat
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-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
Make this test a bit stricter. NFC. llvm-svn: 226285
2015-01-17 00:02:03 +08:00
// CHECK: define linkonce_odr x86_thiscallcc %class.A* @"\01??0A@@QAE@XZ"({{.*}}) {{.*}} comdat
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
Make this test a bit stricter. NFC. llvm-svn: 226285
2015-01-17 00:02:03 +08:00
// CHECK: define linkonce_odr x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}}) {{.*}} comdat
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