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

assertion is failing for some tests.

llvm-svn: 71779

llvm-svn: 71769

asm construct into an assertion failure.

llvm-svn: 71757

Basically, there was a situation where it was getting an empty vector and doing
a .back() on that. Which isn't cool.

llvm-svn: 71746

block with its unique predecessor.  Change the code to assert if that is not
the case, instead of trying to handle situations where the block has
multiple predecessors.

llvm-svn: 71744

of exception handling builtin sjlj targets in functions turns out not to 
be necessary. Marking the intrinsic implementation in the .td file as 
defining all registers is sufficient to get the context saved properly by 
the containing function.

llvm-svn: 71743

Dan was trying to catch the case where a basic block ends with a conditional
branch to the fall-through block.  In this case, all the instructions have
been moved out of FromBBI, leaving it empty.  It cannot end with a
conditional branch.  As the existing comment indicates, it will always fall
through to the next block.  If the block already had the next block (NBB)
listed as a successor, the preceding loop has a check for that and does not
remove it.  Thus, we need to check and add the successor only when it is
not already listed.

With Dan's change, the empty block often ends up with the fall-through
successor listed twice.  This exposed the problem in pr4195, where
CodePlacementOpt did not handle the same predecessor listed more than once.
It is also at least partially responsible for pr4202 and probably a similar
issue with Thumb branches being out of range.

llvm-svn: 71742

llvm-svn: 71741

llvm-svn: 71740

field name.  No functional changes.

llvm-svn: 71739

llvm-svn: 71726

booleans. This gives a better indication of what the "addReg()" is
doing. Remembering what all of those booleans mean isn't easy, especially if you
aren't spending all of your time in that code.

I took Jakob's suggestion and made it illegal to pass in "true" for the
flag. This should hopefully prevent any unintended misuse of this (by reverting
to the old way of using addReg()).

llvm-svn: 71722

belonged. The variable declaration stuff wasn't happy with it where it
was. Sorry that the testcase is so big. Bugpoint wasn't able to reduce it
successfully.

llvm-svn: 71714

llvm-svn: 71678

llvm-svn: 71645

operand was killed, the kill needs to be removed from regB's VarInfo.

llvm-svn: 71635

a supporting preliminary patch for GCC-compatible SjLJ exception handling. Note that these intrinsics are not designed to be invoked directly by the user, but
rather used by the front-end as target hooks for exception handling.

llvm-svn: 71610