llvm/win32
Duncan Sands b0f1e1780c Add a new codegen pass that normalizes dwarf exception handling
code in preparation for code generation.  The main thing it does
is handle the case when eh.exception calls (and, in a future
patch, eh.selector calls) are far away from landing pads.  Right
now in practice you only find eh.exception calls close to landing
pads: either in a landing pad (the common case) or in a landing
pad successor, due to loop passes shifting them about.  However
future exception handling improvements will result in calls far
from landing pads:
(1) Inlining of rewinds.  Consider the following case:
In function @f:
...
  invoke @g to label %normal unwind label %unwinds
...
unwinds:
  %ex = call i8* @llvm.eh.exception()
...

In function @g:
...
  invoke @something to label %continue unwind label %handler
...
handler:
  %ex = call i8* @llvm.eh.exception()
... perform cleanups ...
  "rethrow exception"

Now inline @g into @f.  Currently this is turned into:
In function @f:
...
  invoke @something to label %continue unwind label %handler
...
handler:
  %ex = call i8* @llvm.eh.exception()
... perform cleanups ...
  invoke "rethrow exception" to label %normal unwind label %unwinds
unwinds:
  %ex = call i8* @llvm.eh.exception()
...

However we would like to simplify invoke of "rethrow exception" into
a branch to the %unwinds label.  Then %unwinds is no longer a landing
pad, and the eh.exception call there is then far away from any landing
pads.

(2) Using the unwind instruction for cleanups.
It would be nice to have codegen handle the following case:
  invoke @something to label %continue unwind label %run_cleanups
...
handler:
... perform cleanups ...
  unwind

This requires turning "unwind" into a library call, which
necessarily takes a pointer to the exception as an argument
(this patch also does this unwind lowering).  But that means
you are using eh.exception again far from a landing pad.

(3) Bugpoint simplifications.  When bugpoint is simplifying
exception handling code it often generates eh.exception calls
far from a landing pad, which then causes codegen to assert.
Bugpoint then latches on to this assertion and loses sight
of the original problem.

Note that it is currently rare for this pass to actually do
anything.  And in fact it normally shouldn't do anything at
all given the code coming out of llvm-gcc!  But it does fire
a few times in the testsuite.  As far as I can see this is
almost always due to the LoopStrengthReduce codegen pass
introducing pointless loop preheader blocks which are landing
pads and only contain a branch to another block.  This other
block contains an eh.exception call.  So probably by tweaking
LoopStrengthReduce a bit this can be avoided.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72276 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-22 20:36:31 +00:00
..
Analysis Fix PR3415 (infinite loop in EscapeAnalysis) by 2009-01-28 11:33:59 +00:00
Archive
AsmParser More updates to VC proj... 2009-01-26 22:03:42 +00:00
Bitcode
bugpoint
CBackend
CodeGen Add a new codegen pass that normalizes dwarf exception handling 2009-05-22 20:36:31 +00:00
Configure
ExecutionEngine
Fibonacci
Linker
llc
lli
llvm-ar
llvm-as
llvm-bcanalyzer
llvm-dis
llvm-ld
llvm-link
llvm-nm
llvm-prof
llvm-ranlib
opt
Support
System
TableGen
Target Add files to VC++ projects. 2008-11-13 21:18:54 +00:00
Transforms Handful of fixes to the VC project files. 2009-01-22 23:05:37 +00:00
VMCore
x86 Add files to VC++ projects. 2008-11-13 21:18:54 +00:00
clang.sln remove unavailable clang project 2008-11-08 01:02:44 +00:00
common.vsprops
config.h Update hand-crafted VC++ build. 2009-02-02 19:22:02 +00:00
dobison.cmd
doflex.cmd
llvm.sln
unistd.h