Commit Graph

16 Commits

Author SHA1 Message Date
John McCall ad5d61e227 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-23 21:56:41 +00:00
John McCall 2b7fc3828e Teach IR generation how to lazily emit cleanups. This has a lot of advantages,
mostly in avoiding unnecessary work at compile time but also in producing more
sensible block orderings.

Move the destructor cleanups for local variables over to use lazy cleanups.
Eventually all cleanups will do this;  for now we have some awkward code
duplication.

Tell IR generation just to never produce landing pads in -fno-exceptions.
This is a much more comprehensive solution to a problem which previously was
half-solved by checks in most cleanup-generation spots.

llvm-svn: 108270
2010-07-13 20:32:21 +00:00
John McCall 2b6ac78e07 Stop testing for specific basic block numbers in this test.
llvm-svn: 107632
2010-07-06 02:14:28 +00:00
John McCall bd30929e4d 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 01:34:17 +00:00
Douglas Gregor ff73a9e380 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-08 22:20:28 +00:00
Douglas Gregor 14653638de Fix test for Release-Asserts build
llvm-svn: 103337
2010-05-08 16:04:01 +00:00
Douglas Gregor e60e41add9 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-06 17:25:47 +00:00
Daniel Dunbar 5140d1b75e Update tests in -Asserts mode. These tests really need to be rewritten...
llvm-svn: 95658
2010-02-09 08:22:03 +00:00
Mike Stump 2f7b246a47 Fix for Release-Asserts.
llvm-svn: 93347
2010-01-13 20:57:29 +00:00
Daniel Dunbar 8fbe78f6fc 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-15 20:14:24 +00:00
Douglas Gregor 3d9e90ae3e 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 01:51:31 +00:00
Douglas Gregor e05b765b0d Tweak the code-generation-for-condition-variables test case to get to what we want to test
llvm-svn: 89818
2009-11-25 00:29:29 +00:00
Douglas Gregor 7bab5ff8e7 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 00:27:52 +00:00
Douglas Gregor 680f861d74 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-24 21:15:44 +00:00
Douglas Gregor dcf1962405 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-24 17:07:59 +00:00
Douglas Gregor 965f450d42 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-24 16:43:22 +00:00