| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 25514
|
| |
|
|
| |
llvm-svn: 21480
|
| |
|
|
| |
llvm-svn: 21427
|
| |
|
|
|
|
|
| |
a nested loop. This fixes Transforms/LoopUnroll/2005-03-06-BadLoopInfoUpdate.ll
and PR532
llvm-svn: 20493
|
| |
|
|
| |
llvm-svn: 19380
|
| |
|
|
|
|
| |
Patch contributed by Michael McCracken!
llvm-svn: 18108
|
| |
|
|
|
|
| |
Patch contributed by Morten Ofstad. Thanks Morten!
llvm-svn: 17123
|
| |
|
|
|
|
| |
Patch contributed by Paolo Invernizzi. Thanks Paolo!
llvm-svn: 16368
|
| |
|
|
|
|
|
|
| |
Move include/Config and include/Support into include/llvm/Config,
include/llvm/ADT and include/llvm/Support. From here on out, all LLVM
public header files must be under include/llvm/.
llvm-svn: 16137
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in the size calculation.
This is not something you want to see:
Loop Unroll: F[main] Loop %no_exit Loop Size = 2 Trip Count = 2147483648 - UNROLLING!
The problem was that 2*2147483648 == 0.
Now we get:
Loop Unroll: F[main] Loop %no_exit Loop Size = 2 Trip Count = 2147483648 - TOO LARGE: 4294967296>100
Thanks to some anonymous person playing with the demo page that repeatedly
caused zion to go into swapping land. That's one way to ensure you'll get
a quick bugfix. :)
Testcase here: Transforms/LoopUnroll/2004-05-13-DontUnrollTooMuch.ll
llvm-svn: 13564
|
| |
|
|
| |
llvm-svn: 13081
|
| |
|
|
| |
llvm-svn: 13057
|
| |
|
|
|
|
|
| |
structure to being dynamically computed on demand. This makes updating
loop information MUCH easier.
llvm-svn: 13045
|
| |
|
|
| |
llvm-svn: 13040
|
| |
|
|
|
|
|
|
| |
that the exit block of the loop becomes the new entry block of the function.
This was causing a verifier assertion on 252.eon.
llvm-svn: 13039
|
| |
|
|
|
|
|
| |
using instructions inside of the loop. This should fix the MishaTest failure
from last night.
llvm-svn: 13038
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
block. The primary motivation for doing this is that we can now unroll nested loops.
This makes a pretty big difference in some cases. For example, in 183.equake,
we are now beating the native compiler with the CBE, and we are a lot closer
with LLC.
I'm now going to play around a bit with the unroll factor and see what effect
it really has.
llvm-svn: 13034
|
| |
|
|
|
|
| |
While we're at it, add support for updating loop information correctly.
llvm-svn: 13033
|
|
|
limited. Even in it's extremely simple state (it can only *fully* unroll single
basic block loops that execute a constant number of times), it already helps improve
performance a LOT on some benchmarks, particularly with the native code generators.
llvm-svn: 13028
|