| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
header is just the entry block to the loop, and it needn't be at
the top of the loop in the code layout.
Remove the code that suppressed loop alignment for outer loops,
so that outer loops are aligned.
llvm-svn: 84158
|
|
|
|
| |
llvm-svn: 83437
|
|
|
|
|
|
| |
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
|