| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
correctly indicates whether it changed the code.
llvm-svn: 72038
|
|
|
|
| |
llvm-svn: 71726
|
|
|
|
|
|
| |
don't want to add nops in the outer loop for the sake of aligning the inner loop.
llvm-svn: 71609
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 71363
|
|
|
|
| |
llvm-svn: 71291
|
|
|
|
| |
llvm-svn: 71242
|
|
|
|
| |
llvm-svn: 71214
|
|
|
|
| |
llvm-svn: 71211
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unconditional branch to the outside of the loop. e.g.
/// A:
/// ...
/// <fallthrough to B>
///
/// B: --> loop header
/// ...
/// jcc <cond> C, [exit]
///
/// C:
/// ...
/// jmp B
///
/// ==>
///
/// A:
/// ...
/// jmp B
///
/// C: --> new loop header
/// ...
/// <fallthough to B>
///
/// B:
/// ...
/// jcc <cond> C, [exit]
llvm-svn: 71209
|
|
|
|
| |
llvm-svn: 71151
|
|
llvm-svn: 71150
|