Commit Graph

6 Commits

Author SHA1 Message Date
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 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 9154b5dffe Ensure that destructors are called for NRVO'd objects when the
function does not return. Thanks to Eli for pointing out this corner
case.

llvm-svn: 103941
2010-05-17 15:52:46 +00:00
Douglas Gregor 4f0ed42601 Attempt to satisfy Release-Asserts build
llvm-svn: 103879
2010-05-15 17:28:53 +00:00
Douglas Gregor 170125648c When applying the named return value optimization, we still need to
destroy the variable along the exceptional edge; it's only during
normal execution that we avoid destroying this variable.

llvm-svn: 103872
2010-05-15 16:39:56 +00:00
Douglas Gregor 290c93ec0d Implement a simple form of the C++ named return value optimization for
return statements. We perform NRVO only when all of the return
statements in the function return the same variable. Fixes some link
failures in Boost.Interprocess (which is relying on NRVO), and
probably improves performance for some C++ applications.

llvm-svn: 103867
2010-05-15 06:46:45 +00:00