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/condition.cpp

318 lines
6.5 KiB
C++
Raw Normal View History

Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'. - This is designed to make it obvious that %clang_cc1 is a "test variable" which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it can be useful to redefine what gets run as 'clang -cc1' (for example, to set a default target). llvm-svn: 91446
2009-12-16 04:14:24 +08:00
// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -emit-llvm -o - %s | FileCheck %s
Introduce cleanup scopes for "if" statements in two places: - Outside the "if", to ensure that we destroy the condition variable at the end of the "if" statement rather than at the end of the block containing the "if" statement. - Inside the "then" and "else" branches, so that we emit then- or else-local cleanups at the end of the corresponding block when the block is not a compound statement. To make adding these new cleanup scopes easier (and since switch/do/while will all need the same treatment), added the CleanupScope RAII object to introduce a new cleanup scope and make sure it gets cleaned up. llvm-svn: 89773
2009-11-25 00:43:22 +08:00
void *f();
template <typename T> T* g() {
if (T* t = f())
return t;
return 0;
}
void h() {
void *a = g<void>();
}
struct X {
X();
When instantiating statements that involve conditions (if, while, do, for, and switch), be careful to construct the full expressions as soon as we perform template instantation, so we don't either forget to call temporary destructors or destroy temporaries at the wrong time. This is the template-instantiation analogue to r103187, during which I hadn't realized that the issue would affect the handling of these constructs differently inside and outside of templates. Fixes a regression in Boost.Function. llvm-svn: 103357
2010-05-09 06:20:28 +08:00
X(const X&);
Introduce cleanup scopes for "if" statements in two places: - Outside the "if", to ensure that we destroy the condition variable at the end of the "if" statement rather than at the end of the block containing the "if" statement. - Inside the "then" and "else" branches, so that we emit then- or else-local cleanups at the end of the corresponding block when the block is not a compound statement. To make adding these new cleanup scopes easier (and since switch/do/while will all need the same treatment), added the CleanupScope RAII object to introduce a new cleanup scope and make sure it gets cleaned up. llvm-svn: 89773
2009-11-25 00:43:22 +08:00
~X();
operator bool();
};
struct Y {
Y();
~Y();
};
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
X getX();
CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail. llvm-svn: 188447
2013-08-15 14:47:53 +08:00
// CHECK-LABEL: define void @_Z11if_destructi(
Introduce cleanup scopes for "if" statements in two places: - Outside the "if", to ensure that we destroy the condition variable at the end of the "if" statement rather than at the end of the block containing the "if" statement. - Inside the "then" and "else" branches, so that we emit then- or else-local cleanups at the end of the corresponding block when the block is not a compound statement. To make adding these new cleanup scopes easier (and since switch/do/while will all need the same treatment), added the CleanupScope RAII object to introduce a new cleanup scope and make sure it gets cleaned up. llvm-svn: 89773
2009-11-25 00:43:22 +08:00
void if_destruct(int z) {
// Verify that the condition variable is destroyed at the end of the
// "if" statement.
// CHECK: call void @_ZN1XC1Ev
// CHECK: call zeroext i1 @_ZN1XcvbEv
if (X x = X()) {
// CHECK: store i32 18
z = 18;
}
// CHECK: call void @_ZN1XD1Ev
// CHECK: store i32 17
z = 17;
// CHECK: call void @_ZN1XC1Ev
if (X x = X())
Y y;
Fix for Release-Asserts. llvm-svn: 93347
2010-01-14 04:57:29 +08:00
// CHECK: br
Introduce cleanup scopes for "if" statements in two places: - Outside the "if", to ensure that we destroy the condition variable at the end of the "if" statement rather than at the end of the block containing the "if" statement. - Inside the "then" and "else" branches, so that we emit then- or else-local cleanups at the end of the corresponding block when the block is not a compound statement. To make adding these new cleanup scopes easier (and since switch/do/while will all need the same treatment), added the CleanupScope RAII object to introduce a new cleanup scope and make sure it gets cleaned up. llvm-svn: 89773
2009-11-25 00:43:22 +08:00
// CHECK: call void @_ZN1YC1Ev
// CHECK: call void @_ZN1YD1Ev
Fix for Release-Asserts. llvm-svn: 93347
2010-01-14 04:57:29 +08:00
// CHECK: br
Introduce cleanup scopes for "if" statements in two places: - Outside the "if", to ensure that we destroy the condition variable at the end of the "if" statement rather than at the end of the block containing the "if" statement. - Inside the "then" and "else" branches, so that we emit then- or else-local cleanups at the end of the corresponding block when the block is not a compound statement. To make adding these new cleanup scopes easier (and since switch/do/while will all need the same treatment), added the CleanupScope RAII object to introduce a new cleanup scope and make sure it gets cleaned up. llvm-svn: 89773
2009-11-25 00:43:22 +08:00
// CHECK: call void @_ZN1XD1Ev
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
// CHECK: call void @_Z4getXv
// CHECK: call zeroext i1 @_ZN1XcvbEv
// CHECK: call void @_ZN1XD1Ev
// CHECK: br
if (getX()) { }
// CHECK: ret
Introduce cleanup scopes for "if" statements in two places: - Outside the "if", to ensure that we destroy the condition variable at the end of the "if" statement rather than at the end of the block containing the "if" statement. - Inside the "then" and "else" branches, so that we emit then- or else-local cleanups at the end of the corresponding block when the block is not a compound statement. To make adding these new cleanup scopes easier (and since switch/do/while will all need the same treatment), added the CleanupScope RAII object to introduce a new cleanup scope and make sure it gets cleaned up. llvm-svn: 89773
2009-11-25 00:43:22 +08:00
}
Explicitly store the condition variable within switch statements, and make sure that this variable is destroyed when we exit the switch statement. llvm-svn: 89776
2009-11-25 01:07:59 +08:00
struct ConvertibleToInt {
ConvertibleToInt();
~ConvertibleToInt();
operator int();
};
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
ConvertibleToInt getConvToInt();
Explicitly store the condition variable within switch statements, and make sure that this variable is destroyed when we exit the switch statement. llvm-svn: 89776
2009-11-25 01:07:59 +08:00
void switch_destruct(int z) {
// CHECK: call void @_ZN16ConvertibleToIntC1Ev
switch (ConvertibleToInt conv = ConvertibleToInt()) {
case 0:
break;
default:
// CHECK: store i32 19
z = 19;
break;
}
// CHECK: call void @_ZN16ConvertibleToIntD1Ev
// CHECK: store i32 20
z = 20;
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
// CHECK: call void @_Z12getConvToIntv
// CHECK: call i32 @_ZN16ConvertibleToIntcviEv
// CHECK: call void @_ZN16ConvertibleToIntD1Ev
switch(getConvToInt()) {
case 0:
break;
}
// CHECK: store i32 27
z = 27;
// CHECK: ret
Explicitly store the condition variable within switch statements, and make sure that this variable is destroyed when we exit the switch statement. llvm-svn: 89776
2009-11-25 01:07:59 +08:00
}
Clean up the AST for while loops and fix several problems with cleanups for while loops: 1) Make sure that we destroy the condition variable of a while statement each time through the loop for, e.g., while (shared_ptr<WorkInt> p = getWorkItem()) { // ... } 2) Make sure that we always enter a new cleanup scope for the body of the while loop, even when there is no compound expression, e.g., while (blah) RAIIObject raii(blah+1); llvm-svn: 89800
2009-11-25 05:15:44 +08:00
int foo();
CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail. llvm-svn: 188447
2013-08-15 14:47:53 +08:00
// CHECK-LABEL: define void @_Z14while_destructi
Clean up the AST for while loops and fix several problems with cleanups for while loops: 1) Make sure that we destroy the condition variable of a while statement each time through the loop for, e.g., while (shared_ptr<WorkInt> p = getWorkItem()) { // ... } 2) Make sure that we always enter a new cleanup scope for the body of the while loop, even when there is no compound expression, e.g., while (blah) RAIIObject raii(blah+1); llvm-svn: 89800
2009-11-25 05:15:44 +08:00
void while_destruct(int z) {
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK: [[Z:%.*]] = alloca i32
// CHECK: [[CLEANUPDEST:%.*]] = alloca i32
Clean up the AST for while loops and fix several problems with cleanups for while loops: 1) Make sure that we destroy the condition variable of a while statement each time through the loop for, e.g., while (shared_ptr<WorkInt> p = getWorkItem()) { // ... } 2) Make sure that we always enter a new cleanup scope for the body of the while loop, even when there is no compound expression, e.g., while (blah) RAIIObject raii(blah+1); llvm-svn: 89800
2009-11-25 05:15:44 +08:00
while (X x = X()) {
// CHECK: call void @_ZN1XC1Ev
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK-NEXT: [[COND:%.*]] = call zeroext i1 @_ZN1XcvbEv
// CHECK-NEXT: br i1 [[COND]]
Clean up the AST for while loops and fix several problems with cleanups for while loops: 1) Make sure that we destroy the condition variable of a while statement each time through the loop for, e.g., while (shared_ptr<WorkInt> p = getWorkItem()) { // ... } 2) Make sure that we always enter a new cleanup scope for the body of the while loop, even when there is no compound expression, e.g., while (blah) RAIIObject raii(blah+1); llvm-svn: 89800
2009-11-25 05:15:44 +08:00
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// Loop-exit staging block.
Revise cleanup IR generation to fix a major bug with cleanups (PR7686) as well as some significant asymptotic inefficiencies with threading multiple jumps through deep cleanups. llvm-svn: 109274
2010-07-24 05:56:41 +08:00
// CHECK: store i32 3, i32* [[CLEANUPDEST]]
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK-NEXT: br
// While body.
// CHECK: store i32 21, i32* [[Z]]
Revise cleanup IR generation to fix a major bug with cleanups (PR7686) as well as some significant asymptotic inefficiencies with threading multiple jumps through deep cleanups. llvm-svn: 109274
2010-07-24 05:56:41 +08:00
// CHECK: store i32 0, i32* [[CLEANUPDEST]]
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK-NEXT: br
Clean up the AST for while loops and fix several problems with cleanups for while loops: 1) Make sure that we destroy the condition variable of a while statement each time through the loop for, e.g., while (shared_ptr<WorkInt> p = getWorkItem()) { // ... } 2) Make sure that we always enter a new cleanup scope for the body of the while loop, even when there is no compound expression, e.g., while (blah) RAIIObject raii(blah+1); llvm-svn: 89800
2009-11-25 05:15:44 +08:00
z = 21;
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// Cleanup.
Clean up the AST for while loops and fix several problems with cleanups for while loops: 1) Make sure that we destroy the condition variable of a while statement each time through the loop for, e.g., while (shared_ptr<WorkInt> p = getWorkItem()) { // ... } 2) Make sure that we always enter a new cleanup scope for the body of the while loop, even when there is no compound expression, e.g., while (blah) RAIIObject raii(blah+1); llvm-svn: 89800
2009-11-25 05:15:44 +08:00
// CHECK: call void @_ZN1XD1Ev
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK-NEXT: [[DEST:%.*]] = load i32* [[CLEANUPDEST]]
// CHECK-NEXT: switch i32 [[DEST]]
Clean up the AST for while loops and fix several problems with cleanups for while loops: 1) Make sure that we destroy the condition variable of a while statement each time through the loop for, e.g., while (shared_ptr<WorkInt> p = getWorkItem()) { // ... } 2) Make sure that we always enter a new cleanup scope for the body of the while loop, even when there is no compound expression, e.g., while (blah) RAIIObject raii(blah+1); llvm-svn: 89800
2009-11-25 05:15:44 +08:00
}
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK: store i32 22, i32* [[Z]]
Clean up the AST for while loops and fix several problems with cleanups for while loops: 1) Make sure that we destroy the condition variable of a while statement each time through the loop for, e.g., while (shared_ptr<WorkInt> p = getWorkItem()) { // ... } 2) Make sure that we always enter a new cleanup scope for the body of the while loop, even when there is no compound expression, e.g., while (blah) RAIIObject raii(blah+1); llvm-svn: 89800
2009-11-25 05:15:44 +08:00
z = 22;
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
// CHECK: call void @_Z4getXv
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK-NEXT: call zeroext i1 @_ZN1XcvbEv
// CHECK-NEXT: call void @_ZN1XD1Ev
// CHECK-NEXT: br
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
while(getX()) { }
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK: store i32 25, i32* [[Z]]
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
z = 25;
// CHECK: ret
Clean up the AST for while loops and fix several problems with cleanups for while loops: 1) Make sure that we destroy the condition variable of a while statement each time through the loop for, e.g., while (shared_ptr<WorkInt> p = getWorkItem()) { // ... } 2) Make sure that we always enter a new cleanup scope for the body of the while loop, even when there is no compound expression, e.g., while (blah) RAIIObject raii(blah+1); llvm-svn: 89800
2009-11-25 05:15:44 +08:00
}
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail. llvm-svn: 188447
2013-08-15 14:47:53 +08:00
// CHECK-LABEL: define void @_Z12for_destructi(
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
void for_destruct(int z) {
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK: [[Z:%.*]] = alloca i32
Revise cleanup IR generation to fix a major bug with cleanups (PR7686) as well as some significant asymptotic inefficiencies with threading multiple jumps through deep cleanups. llvm-svn: 109274
2010-07-24 05:56:41 +08:00
// CHECK: [[CLEANUPDEST:%.*]] = alloca i32
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK: [[I:%.*]] = alloca i32
Tweak the code-generation-for-condition-variables test case to get to what we want to test llvm-svn: 89818
2009-11-25 08:29:29 +08:00
// CHECK: call void @_ZN1YC1Ev
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK-NEXT: br
// -> %for.cond
for(Y y = Y(); X x = X(); ++z) {
// %for.cond: The loop condition.
Implement proper cleanup semantics for condition variables in for statements, e.g., for(; X x = X(); ) { ... } Daniel or Anders, please review! llvm-svn: 89832
2009-11-25 09:51:31 +08:00
// CHECK: call void @_ZN1XC1Ev
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK-NEXT: [[COND:%.*]] = call zeroext i1 @_ZN1XcvbEv(
// CHECK-NEXT: br i1 [[COND]]
// -> %for.body, %for.cond.cleanup
// %for.cond.cleanup: Exit cleanup staging.
Revise cleanup IR generation to fix a major bug with cleanups (PR7686) as well as some significant asymptotic inefficiencies with threading multiple jumps through deep cleanups. llvm-svn: 109274
2010-07-24 05:56:41 +08:00
// CHECK: store i32 2, i32* [[CLEANUPDEST]]
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK-NEXT: br
// -> %cleanup
// %for.body:
// CHECK: store i32 23, i32* [[Z]]
// CHECK-NEXT: br
// -> %for.inc
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
z = 23;
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// %for.inc:
// CHECK: [[TMP:%.*]] = load i32* [[Z]]
// CHECK-NEXT: [[INC:%.*]] = add nsw i32 [[TMP]], 1
// CHECK-NEXT: store i32 [[INC]], i32* [[Z]]
Revise cleanup IR generation to fix a major bug with cleanups (PR7686) as well as some significant asymptotic inefficiencies with threading multiple jumps through deep cleanups. llvm-svn: 109274
2010-07-24 05:56:41 +08:00
// CHECK-NEXT: store i32 0, i32* [[CLEANUPDEST]]
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK-NEXT: br
// -> %cleanup
// %cleanup: Destroys X.
Implement proper cleanup semantics for condition variables in for statements, e.g., for(; X x = X(); ) { ... } Daniel or Anders, please review! llvm-svn: 89832
2009-11-25 09:51:31 +08:00
// CHECK: call void @_ZN1XD1Ev
Revise cleanup IR generation to fix a major bug with cleanups (PR7686) as well as some significant asymptotic inefficiencies with threading multiple jumps through deep cleanups. llvm-svn: 109274
2010-07-24 05:56:41 +08:00
// CHECK-NEXT: [[YDESTTMP:%.*]] = load i32* [[CLEANUPDEST]]
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK-NEXT: switch i32 [[YDESTTMP]]
Revise cleanup IR generation to fix a major bug with cleanups (PR7686) as well as some significant asymptotic inefficiencies with threading multiple jumps through deep cleanups. llvm-svn: 109274
2010-07-24 05:56:41 +08:00
// 0 -> %cleanup.cont, default -> %cleanup1
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// %cleanup.cont: (eliminable)
// CHECK: br
// -> %for.cond
Revise cleanup IR generation to fix a major bug with cleanups (PR7686) as well as some significant asymptotic inefficiencies with threading multiple jumps through deep cleanups. llvm-svn: 109274
2010-07-24 05:56:41 +08:00
// %cleanup1: Destroys Y.
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK: call void @_ZN1YD1Ev(
// CHECK-NEXT: br
// -> %for.end
}
// %for.end:
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
// CHECK: store i32 24
z = 24;
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK-NEXT: store i32 0, i32* [[I]]
// CHECK-NEXT: br
// -> %for.cond6
// %for.cond6:
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
// CHECK: call void @_Z4getXv
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK-NEXT: call zeroext i1 @_ZN1XcvbEv
// CHECK-NEXT: call void @_ZN1XD1Ev
// CHECK-NEXT: br
// -> %for.body10, %for.end16
// %for.body10:
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
// CHECK: br
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// -> %for.inc11
// %for.inc11:
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
// CHECK: call void @_Z4getXv
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// CHECK-NEXT: load i32* [[I]]
// CHECK-NEXT: add
// CHECK-NEXT: store
// CHECK-NEXT: call void @_ZN1XD1Ev
// CHECK-NEXT: br
// -> %for.cond6
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
int i = 0;
for(; getX(); getX(), ++i) { }
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
// %for.end16
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
// CHECK: store i32 26
Validated by nightly-test runs on x86 and x86-64 darwin, including after self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. llvm-svn: 107631
2010-07-06 09:34:17 +08:00
z = 26;
// CHECK-NEXT: ret void
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
}
void do_destruct(int z) {
CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail. llvm-svn: 188447
2013-08-15 14:47:53 +08:00
// CHECK-LABEL: define void @_Z11do_destruct
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
do {
// CHECK: store i32 77
z = 77;
// CHECK: call void @_Z4getXv
// CHECK: call zeroext i1 @_ZN1XcvbEv
// CHECK: call void @_ZN1XD1Ev
// CHECK: br
} while (getX());
// CHECK: store i32 99
z = 99;
// CHECK: ret
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
}
When instantiating statements that involve conditions (if, while, do, for, and switch), be careful to construct the full expressions as soon as we perform template instantation, so we don't either forget to call temporary destructors or destroy temporaries at the wrong time. This is the template-instantiation analogue to r103187, during which I hadn't realized that the issue would affect the handling of these constructs differently inside and outside of templates. Fixes a regression in Boost.Function. llvm-svn: 103357
2010-05-09 06:20:28 +08:00
int f(X);
template<typename T>
int instantiated(T x) {
int result;
// CHECK: call void @_ZN1XC1ERKS_
// CHECK: call i32 @_Z1f1X
// CHECK: call void @_ZN1XD1Ev
// CHECK: br
// CHECK: store i32 2
// CHECK: br
// CHECK: store i32 3
if (f(x)) { result = 2; } else { result = 3; }
// CHECK: call void @_ZN1XC1ERKS_
// CHECK: call i32 @_Z1f1X
// CHECK: call void @_ZN1XD1Ev
// CHECK: br
// CHECK: store i32 4
// CHECK: br
while (f(x)) { result = 4; }
// CHECK: call void @_ZN1XC1ERKS_
// CHECK: call i32 @_Z1f1X
// CHECK: call void @_ZN1XD1Ev
// CHECK: br
// CHECK: store i32 6
// CHECK: br
// CHECK: call void @_ZN1XC1ERKS_
// CHECK: call i32 @_Z1f1X
// CHECK: store i32 5
// CHECK: call void @_ZN1XD1Ev
// CHECK: br
for (; f(x); f(x), result = 5) {
result = 6;
}
// CHECK: call void @_ZN1XC1ERKS_
// CHECK: call i32 @_Z1f1X
// CHECK: call void @_ZN1XD1Ev
// CHECK: switch i32
// CHECK: store i32 7
// CHECK: store i32 8
switch (f(x)) {
case 0:
result = 7;
break;
case 1:
result = 8;
}
// CHECK: store i32 9
// CHECK: br
// CHECK: call void @_ZN1XC1ERKS_
// CHECK: call i32 @_Z1f1X
// CHECK: call void @_ZN1XD1Ev
// CHECK: br
do {
result = 9;
} while (f(x));
// CHECK: store i32 10
// CHECK: call void @_ZN1XC1ERKS_
// CHECK: call zeroext i1 @_ZN1XcvbEv
// CHECK: call void @_ZN1XD1Ev
// CHECK: br
do {
result = 10;
} while (X(x));
// CHECK: ret i32
return result;
}
template int instantiated(X);