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-eh-cleanups.cpp

316 lines
12 KiB
C++
Raw Normal View History

[Temporary, Lifetime] Add lifetime marks for temporaries With all MaterializeTemporaryExprs coming with a ExprWithCleanups, it's easy to add correct lifetime.end marks into the right RunCleanupsScope. Differential Revision: http://reviews.llvm.org/D20499 llvm-svn: 274385
2016-07-02 05:08:47 +08:00
// RUN: %clang_cc1 -std=c++11 -emit-llvm %s -o - -triple=i386-pc-win32 -mconstructor-aliases -fexceptions -fcxx-exceptions -fno-rtti | FileCheck -check-prefix WIN32 -check-prefix WIN32-O0 %s
Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'. Much to my surprise, '-disable-llvm-optzns' which I thought was the magical flag I wanted to get at the raw LLVM IR coming out of Clang deosn't do that. It still runs some passes over the IR. I don't want that, I really want the *raw* IR coming out of Clang and I strongly suspect everyone else using it is in the same camp. There is actually a flag that does what I want that I didn't know about called '-disable-llvm-passes'. I suspect many others don't know about it either. It both does what I want and is much simpler. This removes the confusing version and makes that spelling of the flag an alias for '-disable-llvm-passes'. I've also moved everything in Clang to use the 'passes' spelling as it seems both more accurate (*all* LLVM passes are disabled, not just optimizations) and much easier to remember and spell correctly. This is part of simplifying how Clang drives LLVM to make it cleaner to wire up to the new pass manager. Differential Revision: https://reviews.llvm.org/D28047 llvm-svn: 290392
2016-12-23 08:23:01 +08:00
// RUN: %clang_cc1 -std=c++11 -emit-llvm -O3 -disable-llvm-passes %s -o - -triple=i386-pc-win32 -mconstructor-aliases -fexceptions -fcxx-exceptions -fno-rtti | FileCheck -check-prefix WIN32 -check-prefix WIN32-O3 -check-prefix WIN32-LIFETIME %s
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
struct A {
A();
~A();
int a;
};
A getA();
int TakesTwo(A a, A b);
void HasEHCleanup() {
TakesTwo(getA(), getA());
}
// With exceptions, we need to clean up at least one of these temporaries.
[ms-cxxabi] Use inalloca on win32 when passing non-trivial C++ objects When a non-trivial parameter is present, clang now gathers up all the parameters that lack inreg and puts them into a packed struct. MSVC always aligns each parameter to 4 bytes and no more, so this is a pretty simple struct to lay out. On win64, non-trivial records are passed indirectly. Prior to this change, clang was incorrectly using byval on win64. I'm able to self-host a working clang with this change and additional LLVM patches. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D2636 llvm-svn: 200597
2014-02-01 08:04:45 +08:00
// WIN32-LABEL: define void @"\01?HasEHCleanup@@YAXXZ"() {{.*}} {
// WIN32: %[[base:.*]] = call i8* @llvm.stacksave()
// If this call throws, we have to restore the stack.
Don't emit exceptional stackrestore cleanups around inalloca functions The backend restores the stack pointer after recovering from an exception. This is similar to r245879, but it doesn't try to use the normal cleanup mechanism, so hopefully it won't cause the same breakage. llvm-svn: 249640
2015-10-08 08:17:45 +08:00
// WIN32: call void @"\01?getA@@YA?AUA@@XZ"(%struct.A* sret %{{.*}})
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// If this call throws, we have to cleanup the first temporary.
// WIN32: invoke void @"\01?getA@@YA?AUA@@XZ"(%struct.A* sret %{{.*}})
[ms-cxxabi] Use inalloca on win32 when passing non-trivial C++ objects When a non-trivial parameter is present, clang now gathers up all the parameters that lack inreg and puts them into a packed struct. MSVC always aligns each parameter to 4 bytes and no more, so this is a pretty simple struct to lay out. On win64, non-trivial records are passed indirectly. Prior to this change, clang was incorrectly using byval on win64. I'm able to self-host a working clang with this change and additional LLVM patches. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D2636 llvm-svn: 200597
2014-02-01 08:04:45 +08:00
// If this call throws, we have to cleanup the stacksave.
Don't emit exceptional stackrestore cleanups around inalloca functions The backend restores the stack pointer after recovering from an exception. This is similar to r245879, but it doesn't try to use the normal cleanup mechanism, so hopefully it won't cause the same breakage. llvm-svn: 249640
2015-10-08 08:17:45 +08:00
// WIN32: call i32 @"\01?TakesTwo@@YAHUA@@0@Z"
// WIN32: call void @llvm.stackrestore
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// WIN32: ret void
//
// There should be one dtor call for unwinding from the second getA.
[WinEH] Mark calls inside cleanups as noinline This works around PR25162. The MSVC tables make it very difficult to correctly inline a C++ destructor that contains try / catch. We've attempted to address PR25162 in LLVM's backend, but it feels pretty infeasible. MSVC and ICC both appear to avoid inlining such complex destructors. Long term, we want to fix this by making the inliner smart enough to know when it is inlining into a cleanup, so it can inline simple destructors (~unique_ptr and ~vector) while avoiding destructors containing try / catch. llvm-svn: 251576
2015-10-29 07:06:42 +08:00
// WIN32: cleanuppad
Update clang to use the updated LLVM EH instructions Depends on D15139. Reviewers: rnk Differential Revision: http://reviews.llvm.org/D15140 llvm-svn: 255423
2015-12-12 13:39:21 +08:00
// WIN32: call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
[ms-cxxabi] Use inalloca on win32 when passing non-trivial C++ objects When a non-trivial parameter is present, clang now gathers up all the parameters that lack inreg and puts them into a packed struct. MSVC always aligns each parameter to 4 bytes and no more, so this is a pretty simple struct to lay out. On win64, non-trivial records are passed indirectly. Prior to this change, clang was incorrectly using byval on win64. I'm able to self-host a working clang with this change and additional LLVM patches. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D2636 llvm-svn: 200597
2014-02-01 08:04:45 +08:00
// WIN32-NOT: @"\01??1A@@QAE@XZ"
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// WIN32: }
void TakeRef(const A &a);
int HasDeactivatedCleanups() {
return TakesTwo((TakeRef(A()), A()), (TakeRef(A()), A()));
}
[ms-cxxabi] Use inalloca on win32 when passing non-trivial C++ objects When a non-trivial parameter is present, clang now gathers up all the parameters that lack inreg and puts them into a packed struct. MSVC always aligns each parameter to 4 bytes and no more, so this is a pretty simple struct to lay out. On win64, non-trivial records are passed indirectly. Prior to this change, clang was incorrectly using byval on win64. I'm able to self-host a working clang with this change and additional LLVM patches. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D2636 llvm-svn: 200597
2014-02-01 08:04:45 +08:00
// WIN32-LABEL: define i32 @"\01?HasDeactivatedCleanups@@YAHXZ"() {{.*}} {
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// WIN32: %[[isactive:.*]] = alloca i1
[ms-cxxabi] Use inalloca on win32 when passing non-trivial C++ objects When a non-trivial parameter is present, clang now gathers up all the parameters that lack inreg and puts them into a packed struct. MSVC always aligns each parameter to 4 bytes and no more, so this is a pretty simple struct to lay out. On win64, non-trivial records are passed indirectly. Prior to this change, clang was incorrectly using byval on win64. I'm able to self-host a working clang with this change and additional LLVM patches. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D2636 llvm-svn: 200597
2014-02-01 08:04:45 +08:00
// WIN32: call i8* @llvm.stacksave()
Update clang to account for changes made to LLVM in r203376 llvm-svn: 203377
2014-03-09 15:09:06 +08:00
// WIN32: %[[argmem:.*]] = alloca inalloca [[argmem_ty:<{ %struct.A, %struct.A }>]]
Update Clang tests to handle explicitly typed gep changes in LLVM. llvm-svn: 230783
2015-02-28 03:18:17 +08:00
// WIN32: %[[arg1:.*]] = getelementptr inbounds [[argmem_ty]], [[argmem_ty]]* %[[argmem]], i32 0, i32 1
Don't emit exceptional stackrestore cleanups around inalloca functions The backend restores the stack pointer after recovering from an exception. This is similar to r245879, but it doesn't try to use the normal cleanup mechanism, so hopefully it won't cause the same breakage. llvm-svn: 249640
2015-10-08 08:17:45 +08:00
// WIN32: call x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// WIN32: invoke void @"\01?TakeRef@@YAXABUA@@@Z"
[ms-cxxabi] Use inalloca on win32 when passing non-trivial C++ objects When a non-trivial parameter is present, clang now gathers up all the parameters that lack inreg and puts them into a packed struct. MSVC always aligns each parameter to 4 bytes and no more, so this is a pretty simple struct to lay out. On win64, non-trivial records are passed indirectly. Prior to this change, clang was incorrectly using byval on win64. I'm able to self-host a working clang with this change and additional LLVM patches. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D2636 llvm-svn: 200597
2014-02-01 08:04:45 +08:00
//
// WIN32: invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"(%struct.A* %[[arg1]])
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// WIN32: store i1 true, i1* %[[isactive]]
[ms-cxxabi] Use inalloca on win32 when passing non-trivial C++ objects When a non-trivial parameter is present, clang now gathers up all the parameters that lack inreg and puts them into a packed struct. MSVC always aligns each parameter to 4 bytes and no more, so this is a pretty simple struct to lay out. On win64, non-trivial records are passed indirectly. Prior to this change, clang was incorrectly using byval on win64. I'm able to self-host a working clang with this change and additional LLVM patches. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D2636 llvm-svn: 200597
2014-02-01 08:04:45 +08:00
//
Update Clang tests to handle explicitly typed gep changes in LLVM. llvm-svn: 230783
2015-02-28 03:18:17 +08:00
// WIN32: %[[arg0:.*]] = getelementptr inbounds [[argmem_ty]], [[argmem_ty]]* %[[argmem]], i32 0, i32 0
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// WIN32: invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
// WIN32: invoke void @"\01?TakeRef@@YAXABUA@@@Z"
// WIN32: invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
// WIN32: store i1 false, i1* %[[isactive]]
[ms-cxxabi] Use inalloca on win32 when passing non-trivial C++ objects When a non-trivial parameter is present, clang now gathers up all the parameters that lack inreg and puts them into a packed struct. MSVC always aligns each parameter to 4 bytes and no more, so this is a pretty simple struct to lay out. On win64, non-trivial records are passed indirectly. Prior to this change, clang was incorrectly using byval on win64. I'm able to self-host a working clang with this change and additional LLVM patches. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D2636 llvm-svn: 200597
2014-02-01 08:04:45 +08:00
//
// WIN32: invoke i32 @"\01?TakesTwo@@YAHUA@@0@Z"([[argmem_ty]]* inalloca %[[argmem]])
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// Destroy the two const ref temporaries.
[WinEH] Mark calls inside cleanups as noinline This works around PR25162. The MSVC tables make it very difficult to correctly inline a C++ destructor that contains try / catch. We've attempted to address PR25162 in LLVM's backend, but it feels pretty infeasible. MSVC and ICC both appear to avoid inlining such complex destructors. Long term, we want to fix this by making the inliner smart enough to know when it is inlining into a cleanup, so it can inline simple destructors (~unique_ptr and ~vector) while avoiding destructors containing try / catch. llvm-svn: 251576
2015-10-29 07:06:42 +08:00
// WIN32: call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
// WIN32: call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// WIN32: ret i32
//
// Conditionally destroy arg1.
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// WIN32: %[[cond:.*]] = load i1, i1* %[[isactive]]
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// WIN32: br i1 %[[cond]]
Update clang to use the updated LLVM EH instructions Depends on D15139. Reviewers: rnk Differential Revision: http://reviews.llvm.org/D15140 llvm-svn: 255423
2015-12-12 13:39:21 +08:00
// WIN32: call x86_thiscallcc void @"\01??1A@@QAE@XZ"(%struct.A* %[[arg1]])
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// WIN32: }
// Test putting the cleanups inside a conditional.
int CouldThrow();
int HasConditionalCleanup(bool cond) {
return (cond ? TakesTwo(A(), A()) : CouldThrow());
}
[ms-cxxabi] Use inalloca on win32 when passing non-trivial C++ objects When a non-trivial parameter is present, clang now gathers up all the parameters that lack inreg and puts them into a packed struct. MSVC always aligns each parameter to 4 bytes and no more, so this is a pretty simple struct to lay out. On win64, non-trivial records are passed indirectly. Prior to this change, clang was incorrectly using byval on win64. I'm able to self-host a working clang with this change and additional LLVM patches. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D2636 llvm-svn: 200597
2014-02-01 08:04:45 +08:00
// WIN32-LABEL: define i32 @"\01?HasConditionalCleanup@@YAH_N@Z"(i1 zeroext %{{.*}}) {{.*}} {
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// WIN32: store i1 false
// WIN32: br i1
[ms-cxxabi] Use inalloca on win32 when passing non-trivial C++ objects When a non-trivial parameter is present, clang now gathers up all the parameters that lack inreg and puts them into a packed struct. MSVC always aligns each parameter to 4 bytes and no more, so this is a pretty simple struct to lay out. On win64, non-trivial records are passed indirectly. Prior to this change, clang was incorrectly using byval on win64. I'm able to self-host a working clang with this change and additional LLVM patches. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D2636 llvm-svn: 200597
2014-02-01 08:04:45 +08:00
// WIN32: call i8* @llvm.stacksave()
Don't emit exceptional stackrestore cleanups around inalloca functions The backend restores the stack pointer after recovering from an exception. This is similar to r245879, but it doesn't try to use the normal cleanup mechanism, so hopefully it won't cause the same breakage. llvm-svn: 249640
2015-10-08 08:17:45 +08:00
// WIN32: call x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"(%struct.A* %{{.*}})
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// WIN32: store i1 true
// WIN32: invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"(%struct.A* %{{.*}})
Don't emit exceptional stackrestore cleanups around inalloca functions The backend restores the stack pointer after recovering from an exception. This is similar to r245879, but it doesn't try to use the normal cleanup mechanism, so hopefully it won't cause the same breakage. llvm-svn: 249640
2015-10-08 08:17:45 +08:00
// WIN32: call i32 @"\01?TakesTwo@@YAHUA@@0@Z"
//
Revert r245879. Speculative, might have caused crbug.com/524604 llvm-svn: 245965
2015-08-26 02:43:32 +08:00
// WIN32: call void @llvm.stackrestore
[ms-cxxabi] Use inalloca on win32 when passing non-trivial C++ objects When a non-trivial parameter is present, clang now gathers up all the parameters that lack inreg and puts them into a packed struct. MSVC always aligns each parameter to 4 bytes and no more, so this is a pretty simple struct to lay out. On win64, non-trivial records are passed indirectly. Prior to this change, clang was incorrectly using byval on win64. I'm able to self-host a working clang with this change and additional LLVM patches. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D2636 llvm-svn: 200597
2014-02-01 08:04:45 +08:00
//
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// WIN32: call i32 @"\01?CouldThrow@@YAHXZ"()
[ms-cxxabi] Use inalloca on win32 when passing non-trivial C++ objects When a non-trivial parameter is present, clang now gathers up all the parameters that lack inreg and puts them into a packed struct. MSVC always aligns each parameter to 4 bytes and no more, so this is a pretty simple struct to lay out. On win64, non-trivial records are passed indirectly. Prior to this change, clang was incorrectly using byval on win64. I'm able to self-host a working clang with this change and additional LLVM patches. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D2636 llvm-svn: 200597
2014-02-01 08:04:45 +08:00
//
// Only one dtor in the invoke for arg1
Update clang to use the updated LLVM EH instructions Depends on D15139. Reviewers: rnk Differential Revision: http://reviews.llvm.org/D15140 llvm-svn: 255423
2015-12-12 13:39:21 +08:00
// WIN32: call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
[ms-cxxabi] Use inalloca on win32 when passing non-trivial C++ objects When a non-trivial parameter is present, clang now gathers up all the parameters that lack inreg and puts them into a packed struct. MSVC always aligns each parameter to 4 bytes and no more, so this is a pretty simple struct to lay out. On win64, non-trivial records are passed indirectly. Prior to this change, clang was incorrectly using byval on win64. I'm able to self-host a working clang with this change and additional LLVM patches. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D2636 llvm-svn: 200597
2014-02-01 08:04:45 +08:00
// WIN32-NOT: invoke x86_thiscallcc void @"\01??1A@@QAE@XZ"
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// WIN32: }
// Now test both.
int HasConditionalDeactivatedCleanups(bool cond) {
return (cond ? TakesTwo((TakeRef(A()), A()), (TakeRef(A()), A())) : CouldThrow());
}
[Temporary, Lifetime] Add lifetime marks for temporaries With all MaterializeTemporaryExprs coming with a ExprWithCleanups, it's easy to add correct lifetime.end marks into the right RunCleanupsScope. Differential Revision: http://reviews.llvm.org/D20499 llvm-svn: 274385
2016-07-02 05:08:47 +08:00
// WIN32-O0-LABEL: define i32 @"\01?HasConditionalDeactivatedCleanups@@YAH_N@Z"{{.*}} {
// WIN32-O0: alloca i1
// WIN32-O0: %[[arg1_cond:.*]] = alloca i1
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// Start all four cleanups as deactivated.
[Temporary, Lifetime] Add lifetime marks for temporaries With all MaterializeTemporaryExprs coming with a ExprWithCleanups, it's easy to add correct lifetime.end marks into the right RunCleanupsScope. Differential Revision: http://reviews.llvm.org/D20499 llvm-svn: 274385
2016-07-02 05:08:47 +08:00
// WIN32-O0: store i1 false
// WIN32-O0: store i1 false
// WIN32-O0: store i1 false
// WIN32-O0: store i1 false
// WIN32-O0: br i1
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// True condition.
[Temporary, Lifetime] Add lifetime marks for temporaries With all MaterializeTemporaryExprs coming with a ExprWithCleanups, it's easy to add correct lifetime.end marks into the right RunCleanupsScope. Differential Revision: http://reviews.llvm.org/D20499 llvm-svn: 274385
2016-07-02 05:08:47 +08:00
// WIN32-O0: call x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
// WIN32-O0: store i1 true
// WIN32-O0: invoke void @"\01?TakeRef@@YAXABUA@@@Z"
// WIN32-O0: invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
// WIN32-O0: store i1 true, i1* %[[arg1_cond]]
// WIN32-O0: invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
// WIN32-O0: store i1 true
// WIN32-O0: invoke void @"\01?TakeRef@@YAXABUA@@@Z"
// WIN32-O0: invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
// WIN32-O0: store i1 true
// WIN32-O0: store i1 false, i1* %[[arg1_cond]]
// WIN32-O0: invoke i32 @"\01?TakesTwo@@YAHUA@@0@Z"
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// False condition.
[Temporary, Lifetime] Add lifetime marks for temporaries With all MaterializeTemporaryExprs coming with a ExprWithCleanups, it's easy to add correct lifetime.end marks into the right RunCleanupsScope. Differential Revision: http://reviews.llvm.org/D20499 llvm-svn: 274385
2016-07-02 05:08:47 +08:00
// WIN32-O0: invoke i32 @"\01?CouldThrow@@YAHXZ"()
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
// Two normal cleanups for TakeRef args.
[Temporary, Lifetime] Add lifetime marks for temporaries With all MaterializeTemporaryExprs coming with a ExprWithCleanups, it's easy to add correct lifetime.end marks into the right RunCleanupsScope. Differential Revision: http://reviews.llvm.org/D20499 llvm-svn: 274385
2016-07-02 05:08:47 +08:00
// WIN32-O0: call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
// WIN32-O0-NOT: invoke x86_thiscallcc void @"\01??1A@@QAE@XZ"
// WIN32-O0: ret i32
[ms-cxxabi] Destroy temporary record arguments in the callee Itanium destroys them in the caller at the end of the full expression, but MSVC destroys them in the callee. This is further complicated by the need to emit EH-only destructor cleanups in the caller. This should help clang compile MSVC's debug iterators more correctly. There is still an outstanding issue in PR5064 of a memcpy emitted by the LLVM backend, which is not correct for C++ records. Fixes PR16226. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D929 llvm-svn: 184543
2013-06-21 20:45:15 +08:00
//
// Somewhere in the landing pad soup, we conditionally destroy arg1.
[Temporary, Lifetime] Add lifetime marks for temporaries With all MaterializeTemporaryExprs coming with a ExprWithCleanups, it's easy to add correct lifetime.end marks into the right RunCleanupsScope. Differential Revision: http://reviews.llvm.org/D20499 llvm-svn: 274385
2016-07-02 05:08:47 +08:00
// WIN32-O0: %[[isactive:.*]] = load i1, i1* %[[arg1_cond]]
// WIN32-O0: br i1 %[[isactive]]
// WIN32-O0: call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
// WIN32-O0: }
// WIN32-O3-LABEL: define i32 @"\01?HasConditionalDeactivatedCleanups@@YAH_N@Z"{{.*}} {
// WIN32-O3: alloca i1
// WIN32-O3: alloca i1
// WIN32-O3: %[[arg1_cond:.*]] = alloca i1
// Start all four cleanups as deactivated.
// WIN32-O3: store i1 false
// WIN32-O3: store i1 false
// WIN32-O3: store i1 false
// WIN32-O3: store i1 false
// WIN32-O3: store i1 false
// WIN32-O3: store i1 false
// WIN32-O3: br i1
// True condition.
// WIN32-O3: call x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
// WIN32-O3: store i1 true
// WIN32-O3: invoke void @"\01?TakeRef@@YAXABUA@@@Z"
// WIN32-O3: invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
// WIN32-O3: store i1 true, i1* %[[arg1_cond]]
// WIN32-O3: invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
// WIN32-O3: store i1 true
// WIN32-O3: invoke void @"\01?TakeRef@@YAXABUA@@@Z"
// WIN32-O3: invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
// WIN32-O3: store i1 true
// WIN32-O3: store i1 false, i1* %[[arg1_cond]]
// WIN32-O3: invoke i32 @"\01?TakesTwo@@YAHUA@@0@Z"
// False condition.
// WIN32-O3: invoke i32 @"\01?CouldThrow@@YAHXZ"()
// Two normal cleanups for TakeRef args.
// WIN32-O3: call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
// WIN32-O3-NOT: invoke x86_thiscallcc void @"\01??1A@@QAE@XZ"
// WIN32-O3: ret i32
//
// Somewhere in the landing pad soup, we conditionally destroy arg1.
// WIN32-O3: %[[isactive:.*]] = load i1, i1* %[[arg1_cond]]
// WIN32-O3: br i1 %[[isactive]]
// WIN32-O3: call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
// WIN32-O3: }
Follow-up to r192822: fix Clang assertion when building with -fexceptions llvm-svn: 192875
2013-10-17 17:11:45 +08:00
namespace crash_on_partial_destroy {
struct A {
virtual ~A();
};
struct B : virtual A {
// Has an implicit destructor.
};
struct C : B {
C();
};
void foo();
// We used to crash when emitting this.
C::C() { foo(); }
// Verify that we don't bother with a vbtable lookup when adjusting the this
// pointer to call a base destructor from a constructor while unwinding.
// WIN32-LABEL: define {{.*}} @"\01??0C@crash_on_partial_destroy@@QAE@XZ"{{.*}} {
[WinEH] Remove NewMSEH and enable its behavior by default Testing has shown that it is at least as reliable as the old landingpad pattern matching code. llvm-svn: 249647
2015-10-08 09:13:52 +08:00
// WIN32: cleanuppad
Follow-up to r192822: fix Clang assertion when building with -fexceptions llvm-svn: 192875
2013-10-17 17:11:45 +08:00
//
// We shouldn't do any vbptr loads, just constant GEPs.
// WIN32-NOT: load
Update Clang tests to handle explicitly typed gep changes in LLVM. llvm-svn: 230783
2015-02-28 03:18:17 +08:00
// WIN32: getelementptr i8, i8* %{{.*}}, i32 4
Follow-up to r192822: fix Clang assertion when building with -fexceptions llvm-svn: 192875
2013-10-17 17:11:45 +08:00
// WIN32-NOT: load
// WIN32: bitcast i8* %{{.*}} to %"struct.crash_on_partial_destroy::B"*
[WinEH] Push cleanupendpad scopes around exceptional cleanups We were only doing this for SEH as a special case. Generalize it to all cleanups. llvm-svn: 249748
2015-10-09 05:14:56 +08:00
// WIN32: call x86_thiscallcc void @"\01??1B@crash_on_partial_destroy@@UAE@XZ"
Follow-up to r192822: fix Clang assertion when building with -fexceptions llvm-svn: 192875
2013-10-17 17:11:45 +08:00
//
// WIN32-NOT: load
// WIN32: bitcast %"struct.crash_on_partial_destroy::C"* %{{.*}} to i8*
// WIN32-NOT: load
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// WIN32: getelementptr inbounds i8, i8* %{{.*}}, i32 4
Follow-up to r192822: fix Clang assertion when building with -fexceptions llvm-svn: 192875
2013-10-17 17:11:45 +08:00
// WIN32-NOT: load
// WIN32: bitcast i8* %{{.*}} to %"struct.crash_on_partial_destroy::A"*
Update clang to use the updated LLVM EH instructions Depends on D15139. Reviewers: rnk Differential Revision: http://reviews.llvm.org/D15140 llvm-svn: 255423
2015-12-12 13:39:21 +08:00
// WIN32: call x86_thiscallcc void @"\01??1A@crash_on_partial_destroy@@UAE@XZ"({{.*}})
Follow-up to r192822: fix Clang assertion when building with -fexceptions llvm-svn: 192875
2013-10-17 17:11:45 +08:00
// WIN32: }
}
[WinEH] Don't wrap cleanups in terminate actions _CxxFrameHandler3 calls terminate if a cleanup action throws, regardless of what bits you put in the xdata tables. There's no need to model this in the IR, since we just have to take it out later. llvm-svn: 234448
2015-04-09 06:48:50 +08:00
namespace dont_call_terminate {
struct C {
~C();
};
void g();
void f() {
C c;
g();
}
// WIN32-LABEL: define void @"\01?f@dont_call_terminate@@YAXXZ"()
// WIN32: invoke void @"\01?g@dont_call_terminate@@YAXXZ"()
// WIN32-NEXT: to label %[[cont:[^ ]*]] unwind label %[[lpad:[^ ]*]]
//
// WIN32: [[cont]]
// WIN32: call x86_thiscallcc void @"\01??1C@dont_call_terminate@@QAE@XZ"({{.*}})
//
// WIN32: [[lpad]]
[WinEH] Remove NewMSEH and enable its behavior by default Testing has shown that it is at least as reliable as the old landingpad pattern matching code. llvm-svn: 249647
2015-10-08 09:13:52 +08:00
// WIN32-NEXT: cleanuppad
Update clang to use the updated LLVM EH instructions Depends on D15139. Reviewers: rnk Differential Revision: http://reviews.llvm.org/D15140 llvm-svn: 255423
2015-12-12 13:39:21 +08:00
// WIN32: call x86_thiscallcc void @"\01??1C@dont_call_terminate@@QAE@XZ"({{.*}})
[WinEH] Don't wrap cleanups in terminate actions _CxxFrameHandler3 calls terminate if a cleanup action throws, regardless of what bits you put in the xdata tables. There's no need to model this in the IR, since we just have to take it out later. llvm-svn: 234448
2015-04-09 06:48:50 +08:00
}
[WinEH] Push cleanupendpad scopes around exceptional cleanups We were only doing this for SEH as a special case. Generalize it to all cleanups. llvm-svn: 249748
2015-10-09 05:14:56 +08:00
namespace noexcept_false_dtor {
struct D {
~D() noexcept(false);
};
void f() {
D d;
CouldThrow();
}
}
// WIN32-LABEL: define void @"\01?f@noexcept_false_dtor@@YAXXZ"()
// WIN32: invoke i32 @"\01?CouldThrow@@YAHXZ"()
// WIN32: call x86_thiscallcc void @"\01??1D@noexcept_false_dtor@@QAE@XZ"(%"struct.noexcept_false_dtor::D"* %{{.*}})
// WIN32: cleanuppad
Update clang to use the updated LLVM EH instructions Depends on D15139. Reviewers: rnk Differential Revision: http://reviews.llvm.org/D15140 llvm-svn: 255423
2015-12-12 13:39:21 +08:00
// WIN32: call x86_thiscallcc void @"\01??1D@noexcept_false_dtor@@QAE@XZ"(%"struct.noexcept_false_dtor::D"* %{{.*}})
[WinEH] Push cleanupendpad scopes around exceptional cleanups We were only doing this for SEH as a special case. Generalize it to all cleanups. llvm-svn: 249748
2015-10-09 05:14:56 +08:00
// WIN32: cleanupret
[CodeGen] Emit lifetime.end intrinsic after objects are destructed in landing pads. Previously, lifetime.end intrinsics were inserted only on normal control flows. This prevented StackColoring from merging stack slots for objects that were destroyed on the exception handling control flow since it couldn't tell their lifetime ranges were disjoint. This patch fixes code-gen to emit the intrinsic on both control flows. rdar://problem/22181976 Differential Revision: http://reviews.llvm.org/D18196 llvm-svn: 265197
2016-04-02 06:58:55 +08:00
namespace lifetime_marker {
struct C {
~C();
};
void g();
void f() {
C c;
g();
}
// WIN32-LIFETIME-LABEL: define void @"\01?f@lifetime_marker@@YAXXZ"()
// WIN32-LIFETIME: %[[c:.*]] = alloca %"struct.lifetime_marker::C"
// WIN32-LIFETIME: %[[bc0:.*]] = bitcast %"struct.lifetime_marker::C"* %c to i8*
Update for lifetime intrinsic signature change llvm-svn: 299877
2017-04-11 04:18:45 +08:00
// WIN32-LIFETIME: call void @llvm.lifetime.start.p0i8(i64 1, i8* %[[bc0]])
[CodeGen] Emit lifetime.end intrinsic after objects are destructed in landing pads. Previously, lifetime.end intrinsics were inserted only on normal control flows. This prevented StackColoring from merging stack slots for objects that were destroyed on the exception handling control flow since it couldn't tell their lifetime ranges were disjoint. This patch fixes code-gen to emit the intrinsic on both control flows. rdar://problem/22181976 Differential Revision: http://reviews.llvm.org/D18196 llvm-svn: 265197
2016-04-02 06:58:55 +08:00
// WIN32-LIFETIME: invoke void @"\01?g@lifetime_marker@@YAXXZ"()
// WIN32-LIFETIME-NEXT: to label %[[cont:[^ ]*]] unwind label %[[lpad0:[^ ]*]]
//
Fix test case committed in r265197. The test was failing on some release build because the basic block names I was expecting weren't printed. llvm-svn: 265257
2016-04-03 11:36:22 +08:00
// WIN32-LIFETIME: [[cont]]
[CodeGen] Emit lifetime.end intrinsic after objects are destructed in landing pads. Previously, lifetime.end intrinsics were inserted only on normal control flows. This prevented StackColoring from merging stack slots for objects that were destroyed on the exception handling control flow since it couldn't tell their lifetime ranges were disjoint. This patch fixes code-gen to emit the intrinsic on both control flows. rdar://problem/22181976 Differential Revision: http://reviews.llvm.org/D18196 llvm-svn: 265197
2016-04-02 06:58:55 +08:00
// WIN32-LIFETIME: call x86_thiscallcc void @"\01??1C@lifetime_marker@@QAE@XZ"({{.*}})
// WIN32-LIFETIME: %[[bc1:.*]] = bitcast %"struct.lifetime_marker::C"* %[[c]] to i8*
Update for lifetime intrinsic signature change llvm-svn: 299877
2017-04-11 04:18:45 +08:00
// WIN32-LIFETIME: call void @llvm.lifetime.end.p0i8(i64 1, i8* %[[bc1]])
[CodeGen] Emit lifetime.end intrinsic after objects are destructed in landing pads. Previously, lifetime.end intrinsics were inserted only on normal control flows. This prevented StackColoring from merging stack slots for objects that were destroyed on the exception handling control flow since it couldn't tell their lifetime ranges were disjoint. This patch fixes code-gen to emit the intrinsic on both control flows. rdar://problem/22181976 Differential Revision: http://reviews.llvm.org/D18196 llvm-svn: 265197
2016-04-02 06:58:55 +08:00
//
Fix test case committed in r265197. The test was failing on some release build because the basic block names I was expecting weren't printed. llvm-svn: 265257
2016-04-03 11:36:22 +08:00
// WIN32-LIFETIME: [[lpad0]]
[CodeGen] Emit lifetime.end intrinsic after objects are destructed in landing pads. Previously, lifetime.end intrinsics were inserted only on normal control flows. This prevented StackColoring from merging stack slots for objects that were destroyed on the exception handling control flow since it couldn't tell their lifetime ranges were disjoint. This patch fixes code-gen to emit the intrinsic on both control flows. rdar://problem/22181976 Differential Revision: http://reviews.llvm.org/D18196 llvm-svn: 265197
2016-04-02 06:58:55 +08:00
// WIN32-LIFETIME-NEXT: cleanuppad
// WIN32-LIFETIME: call x86_thiscallcc void @"\01??1C@lifetime_marker@@QAE@XZ"({{.*}})
// WIN32-LIFETIME: cleanupret {{.*}} unwind label %[[lpad1:[^ ]*]]
//
Fix test case committed in r265197. The test was failing on some release build because the basic block names I was expecting weren't printed. llvm-svn: 265257
2016-04-03 11:36:22 +08:00
// WIN32-LIFETIME: [[lpad1]]
[CodeGen] Emit lifetime.end intrinsic after objects are destructed in landing pads. Previously, lifetime.end intrinsics were inserted only on normal control flows. This prevented StackColoring from merging stack slots for objects that were destroyed on the exception handling control flow since it couldn't tell their lifetime ranges were disjoint. This patch fixes code-gen to emit the intrinsic on both control flows. rdar://problem/22181976 Differential Revision: http://reviews.llvm.org/D18196 llvm-svn: 265197
2016-04-02 06:58:55 +08:00
// WIN32-LIFETIME-NEXT: cleanuppad
// WIN32-LIFETIME: %[[bc2:.*]] = bitcast %"struct.lifetime_marker::C"* %[[c]] to i8*
Update for lifetime intrinsic signature change llvm-svn: 299877
2017-04-11 04:18:45 +08:00
// WIN32-LIFETIME: call void @llvm.lifetime.end.p0i8(i64 1, i8* %[[bc2]])
[CodeGen] Emit lifetime.end intrinsic after objects are destructed in landing pads. Previously, lifetime.end intrinsics were inserted only on normal control flows. This prevented StackColoring from merging stack slots for objects that were destroyed on the exception handling control flow since it couldn't tell their lifetime ranges were disjoint. This patch fixes code-gen to emit the intrinsic on both control flows. rdar://problem/22181976 Differential Revision: http://reviews.llvm.org/D18196 llvm-svn: 265197
2016-04-02 06:58:55 +08:00
}
[MS-ABI]V-base dtor called more than needed when throw happens in v-base ctor in window. Need add "complete object flag" check in eh cleanup code. The problem only happen on window ( A MS-ABI issuer ) The nature of the problem is virtual base dtor called more than it is needed after exception throw in inheriting base class(with virtual bases) ctor. The root problem is when throw happen, not all virtual base classes have been contructed, so not all virtual base dtors are need to call for ehcleanup. clang has code to handle vbase initialization: basically add check for "complete object flag" before call to v-base ctor. But that part is missing for cleanup code. To fix this add similar code as v-base init to cleanup code, same algorithm. 1> Add new routine: EmitDtorCompleteObjectHandler With corresponding to EmitCtorCompleteObjectHandler 2> In the EmitDestructorCal Call EmitDtorCompleteObjectHandler when generate ehcleanup inside ctor. Just add check for "complete object flag" before call to v-base dtor. Without my change: ehcleanup: ; preds = %ctor.skip_vbases %13 = cleanuppad within none [], !dbg !66 %14 = bitcast %struct.class_0* %this1 to i8*, !dbg !66 %15 = getelementptr inbounds i8, i8* %14, i64 8, !dbg !66 %16 = bitcast i8* %15 to %struct.class_2*, !dbg !66 call void @"\01??1class_2@@UEAA@XZ"(%struct.class_2* %16) #6 [ "funclet"(token %13) ], !dbg !66 cleanupret from %13 unwind to caller, !dbg !66 with my change: ehcleanup: ; preds = %ctor.skip_vbases %13 = cleanuppad within none [], !dbg !66 %14 = bitcast %struct.class_0* %this1 to i8*, !dbg !66 %15 = getelementptr inbounds i8, i8* %14, i64 8, !dbg !66 %16 = bitcast i8* %15 to %struct.class_2*, !dbg !66 %is_complete_object4 = icmp ne i32 %is_most_derived2, 0, !dbg !66 br i1 %is_complete_object4, label %Dtor.dtor_vbase, label %Dtor.skip_vbase, !d bg !66 Dtor.dtor_vbase: ; preds = %ehcleanup call void @"\01??1class_2@@UEAA@XZ"(%struct.class_2* %16) #6 [ "funclet"(token %13) ], !dbg !66 br label %Dtor.skip_vbase, !dbg !66 Dtor.skip_vbase: ; preds = %Dtor.dtor_vbase, %ehcleanup cleanupret from %13 unwind to caller, !dbg !66 Please let me know you need more info. Patch by Jennifer Yu. Differential Revision: https://reviews.llvm.org/D27358 llvm-svn: 288869
2016-12-07 08:21:45 +08:00
struct class_2 {
class_2();
virtual ~class_2();
};
struct class_1 : virtual class_2 {
class_1(){throw "Unhandled exception";}
virtual ~class_1() {}
};
struct class_0 : class_1 {
class_0() ;
virtual ~class_0() {}
};
class_0::class_0() {
// WIN32: define x86_thiscallcc %struct.class_0* @"\01??0class_0@@QAE@XZ"(%struct.class_0* returned %this, i32 %is_most_derived)
// WIN32: store i32 %is_most_derived, i32* %[[IS_MOST_DERIVED_VAR:.*]], align 4
// WIN32: %[[IS_MOST_DERIVED_VAL:.*]] = load i32, i32* %[[IS_MOST_DERIVED_VAR]]
// WIN32: %[[SHOULD_CALL_VBASE_CTORS:.*]] = icmp ne i32 %[[IS_MOST_DERIVED_VAL]], 0
// WIN32: br i1 %[[SHOULD_CALL_VBASE_CTORS]], label %[[INIT_VBASES:.*]], label %[[SKIP_VBASES:.*]]
// WIN32: [[INIT_VBASES]]
// WIN32: br label %[[SKIP_VBASES]]
// WIN32: [[SKIP_VBASES]]
// ehcleanup:
// WIN32: %[[CLEANUPPAD:.*]] = cleanuppad within none []
// WIN32-NEXT: bitcast %{{.*}}* %{{.*}} to i8*
// WIN32-NEXT: getelementptr inbounds i8, i8* %{{.*}}, i{{.*}} {{.}}
// WIN32-NEXT: bitcast i8* %{{.*}} to %{{.*}}*
// WIN32-NEXT: %[[SHOULD_CALL_VBASE_DTOR:.*]] = icmp ne i32 %[[IS_MOST_DERIVED_VAL]], 0
// WIN32-NEXT: br i1 %[[SHOULD_CALL_VBASE_DTOR]], label %[[DTOR_VBASE:.*]], label %[[SKIP_VBASE:.*]]
// WIN32: [[DTOR_VBASE]]
// WIN32-NEXT: call x86_thiscallcc void @"\01??1class_2@@UAE@XZ"
// WIN32: br label %[[SKIP_VBASE]]
// WIN32: [[SKIP_VBASE]]
}