| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|