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.

llvm-svn: 72276

for ARM.  This fixes rdar://6908807.

llvm-svn: 72269

assuming that the use of the value is in a block dominated by the
"normal" destination. LangRef.html and other documentation sources
don't explicitly guarantee this, but it seems to be assumed in
other places in LLVM at least.

This fixes an assertion failure on the included testcase, which
is derived from the Ada testsuite.

FixUsesBeforeDefs is a temporary measure which I'm looking to
replace with a more capable solution.

llvm-svn: 72266

Emit debug information for globals (which include automatic variables as well because on PIC16 they are emitted as globals by the frontend).

llvm-svn: 72262

llvm-svn: 72254

llvm-svn: 72253

use in expanding SCEVAddExprs with GEPs. The operands of a
SCEVMulExpr need to be multiplied together, not added.

llvm-svn: 72250

indirect call into direct call, thus the verifier would reject something it
previously accepted.

llvm-svn: 72249

This only rejects mismatches between target specific calling convention
and C/LLVM specific calling convention.
There are too many fastcc/C, coldcc/cc42 mismatches in the testsuite, these are
not reject by the verifier.

llvm-svn: 72248

PR4238.

llvm-svn: 72244

DragonFly OS type.

llvm-svn: 72242

llvm-svn: 72239

llvm-svn: 72235

operand is the last in a pattern.  There is no
reason this should be true (although apparently
it always is right now).

llvm-svn: 72232

llvm-svn: 72231

llvm-svn: 72227

PR4238.

llvm-svn: 72223

llvm-svn: 72222

If this causes any new assertion failures that I didn't catch in
testing, the fix is usually to change "&v[0]" to "v.data()" for some
SmallVector v.

llvm-svn: 72221

type as a target independent constant expression.  I confess
that I didn't check that this method works as intended (though
I did test the equivalent hand-written IR a little).  But what
could possibly go wrong!

llvm-svn: 72213

llvm-svn: 72210

llvm-svn: 72209

Instcombine to be more aggressive about using SimplifyDemandedBits
on shift nodes. This allows a shift to be simplified to zero in the
included test case.

llvm-svn: 72204

llvm-svn: 72202

llvm-svn: 72201

bootstrapping.

llvm-svn: 72200

llvm-svn: 72198

llvm-svn: 72197

llvm-svn: 72196

llvm-svn: 72195

llvm-svn: 72194

llvm-svn: 72193

the 'constract function dbg thingy'. Rename some methods to make them consistent
with the rest of the methods. Move the 'Emit' methods to the end of the file.

llvm-svn: 72192

DebugScope refers to a debug region, function or block.

llvm-svn: 72191

llvm-svn: 72184

initialization succeeded or not, rather than just asserting.

llvm-svn: 72182

llvm-svn: 72180

Hopefully this fixes the last build errors on systems with GCC < 4.1.

llvm-svn: 72179

llvm-svn: 72177

all kinds of problems caused by including windows.h and/or config.h in an LLVM header.

llvm-svn: 72174