| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
last use.
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
|
| |
|
|
|
|
| |
don't want to add nops in the outer loop for the sake of aligning the inner loop.
llvm-svn: 71609
|
| |
|
|
|
|
| |
produce side effects.
llvm-svn: 71606
|
| |
|
|
|
|
|
|
|
| |
- moved shrink wrapping code from PrologEpilogInserter.cpp to
new file ShrinkWrapping.cpp.
- moved PEI pass definition into new shared header PEI.h.
llvm-svn: 71588
|
| |
|
|
| |
llvm-svn: 71587
|
| |
|
|
|
|
| |
when doing forward / backward propagation.
llvm-svn: 71574
|
| |
|
|
|
|
|
|
|
|
|
| |
after finding the (unique) layout predecessor. Sometimes a block may be listed
more than once, and processing it more than once in this loop can lead to
inconsistent values for FtTBB/FtFBB, since the AnalyzeBranch method does not
clear these values. There's no point in continuing the loop regardless.
The testcase for this is reduced from the 2003-05-02-DependentPHI SingleSource
test.
llvm-svn: 71536
|
| |
|
|
|
|
|
| |
blast it away.
- Move InlineInfo bookkeeping to bookkeep the correct debug info object.
llvm-svn: 71519
|
| |
|
|
| |
llvm-svn: 71495
|
| |
|
|
|
|
| |
sucessor info.
llvm-svn: 71478
|
| |
|
|
| |
llvm-svn: 71472
|
| |
|
|
| |
llvm-svn: 71457
|
| |
|
|
| |
llvm-svn: 71456
|
| |
|
|
|
|
|
|
| |
type, rather than assume that it does. If the operand is not vector, it
shouldn't be run through ScalarizeVectorOp. This fixes one of the
testcases in PR3886.
llvm-svn: 71453
|