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

llvm-svn: 72210

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

build an integer and cast that to a float.  This fixes a crash 
caused by trying to split an f32 into two f16's.

This changes the behavior in test/CodeGen/XCore/fneg.ll because that 
testcase now triggers a DAGCombine which converts the fneg into an integer
operation.  If someone is interested, it's probably possible to tweak 
the test to generate an actual fneg.

llvm-svn: 72162

llvm-svn: 72114

llvm-svn: 72113

llvm-svn: 72112

fixes dejagnu tests that use these options.

llvm-svn: 72094

llvm-svn: 72078

llvm-svn: 72064

llvm-svn: 72057

function, this could be many, many times. We don't want to re-add variables to
that DIE for each time. We just want to add them once. Check to make sure that
we haven't added them already.

llvm-svn: 72047

correctly indicates whether it changed the code.

llvm-svn: 72038

llvm-svn: 72030

llvm-svn: 72026

llvm-svn: 72024

llvm-svn: 72011

for PostRAScheduler. 

llvm-svn: 71991

llvm-svn: 71987

explicit register define operands.

llvm-svn: 71933

llvm-svn: 71932

was overenthusiastically deleted in r70234.

llvm-svn: 71926

to avoid an ambiguous else.

llvm-svn: 71924

The following is checked:

* Operand counts: All explicit operands must be present.

* Register classes: All physical and virtual register operands must be
  compatible with the register class required by the instruction descriptor.

* Register live intervals: Registers must be defined only once, and must be
  defined before use.

The machine code verifier is enabled with the command-line option
'-verify-machineinstrs', or by defining the environment variable
LLVM_VERIFY_MACHINEINSTRS to the name of a file that will receive all the
verifier errors.

llvm-svn: 71918

Again, no intendtional functionality change.

llvm-svn: 71854

llvm-svn: 71850

llvm-svn: 71848

llvm-svn: 71828

though the classes have been marked with "VISIBILITY_HIDDEN".

llvm-svn: 71827

logical/sane approach to organizing all of the stuff that goes into writing out
DWARF information. Honestly? even this is too complex for what it's supposed to
be doing.

Trivia: It *looks* like there would be functionality changes, however there aren't!
llvm-svn: 71821

Part one of many.

llvm-svn: 71785

llvm-svn: 71784