1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-30 15:32:52 +01:00
Commit Graph

18 Commits

Author SHA1 Message Date
Jeff Cohen
6c42217055 Eliminate tabs and trailing spaces
llvm-svn: 21480
2005-04-23 21:38:35 +00:00
Misha Brukman
53e199440e Remove trailing whitespace
llvm-svn: 21427
2005-04-21 23:48:37 +00:00
Chris Lattner
b4e635cfc4 Fix a bug where we could corrupt a parent loop's header info if we unrolled
a nested loop.  This fixes Transforms/LoopUnroll/2005-03-06-BadLoopInfoUpdate.ll
and PR532

llvm-svn: 20493
2005-03-06 20:57:32 +00:00
Chris Lattner
ee218d4348 Silence VS warnings.
llvm-svn: 19380
2005-01-08 19:37:20 +00:00
Chris Lattner
4b58b75683 Do not consider debug intrinsics in the size computations for loop unrolling.
Patch contributed by Michael McCracken!

llvm-svn: 18108
2004-11-22 17:18:36 +00:00
Reid Spencer
2b5cfe8be8 Correction to allow compilation with Visual C++.
Patch contributed by Morten Ofstad. Thanks Morten!

llvm-svn: 17123
2004-10-18 14:38:48 +00:00
Reid Spencer
c6a8d70cff Convert code to compile with vc7.1.
Patch contributed by Paolo Invernizzi. Thanks Paolo!

llvm-svn: 16368
2004-09-15 17:06:42 +00:00
Reid Spencer
c4abcbefb1 Changes For Bug 352
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
2004-09-01 22:55:40 +00:00
Chris Lattner
b296747100 Fix a nasty bug that caused us to unroll EXTREMELY large loops due to overflow
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
2004-05-13 20:43:31 +00:00
Chris Lattner
602146eea1 Fix PR325
llvm-svn: 13081
2004-04-20 20:26:03 +00:00
Chris Lattner
1849aa8b1f Add #include
llvm-svn: 13057
2004-04-19 03:01:23 +00:00
Chris Lattner
7174acca00 Change the ExitBlocks list from being explicitly contained in the Loop
structure to being dynamically computed on demand.  This makes updating
loop information MUCH easier.

llvm-svn: 13045
2004-04-18 22:14:10 +00:00
Chris Lattner
13140766df Reduce the unrolling limit
llvm-svn: 13040
2004-04-18 18:06:14 +00:00
Chris Lattner
430968ac2f If the preheader of the loop was the entry block of the function, make sure
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
2004-04-18 17:38:42 +00:00
Chris Lattner
199b58db3f Be much more careful about how we update instructions outside of the loop
using instructions inside of the loop.  This should fix the MishaTest failure
from last night.

llvm-svn: 13038
2004-04-18 17:32:39 +00:00
Chris Lattner
33ec7f2f9f After unrolling our single basic block loop, fold it into the preheader and exit
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
2004-04-18 06:27:43 +00:00
Chris Lattner
f2045a8c05 Fix a bug: this does not preserve the CFG!
While we're at it, add support for updating loop information correctly.

llvm-svn: 13033
2004-04-18 05:38:37 +00:00
Chris Lattner
b0d23bf99d Initial checkin of a simple loop unroller. This pass is extremely basic and
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
2004-04-18 05:20:17 +00:00