| Commit message (Collapse) | Author | Age | Files | Lines | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
* Add a stub for the severSplitPHINodes which will allow us to bbextract
  bb's with PHI nodes in them soon.
* Remove unused arguments from findInputsOutputs
* Dramatically simplify the code in findInputsOutputs.  In particular,
  nothing really cares whether or not a PHI node is using something.
* Move moveCodeToFunction to after emitCallAndSwitchStatement as that's the
  order they get called.
* Fix a bug where we would code extract a region that included a call to
  vastart.  Like 'alloca', calls to vastart must stay in the function that
  they are defined in.
* Add some comments.
llvm-svn: 13482
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
from the extracted region.  If the return has 0 or 1 exit blocks, the new
function returns void.  If it has 2 exits, it returns bool, otherwise it
returns a ushort as before.
This allows us to use a conditional branch instruction when there are two
exit blocks, as often happens during block extraction.
llvm-svn: 13481
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
1. Get rid of the silly abort block.  When doing bb extraction, we get one
     abort block for every block extracted, which is kinda annoying.
  2. If the switch ends up having a single destination, turn it into an
     unconditional branch.
I would like to add support for conditional branches, but to do this we will
want to have the function return a bool instead of a ushort.
llvm-svn: 13478
 | 
| | 
| 
| 
|  | 
llvm-svn: 13429
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
%tmp.0 = getelementptr [50 x sbyte]* %ar, uint 0, int 5         ; <sbyte*> [#uses=2]
        %tmp.7 = getelementptr sbyte* %tmp.0, int 8             ; <sbyte*> [#uses=1]
together.  This patch actually allows us to simplify and generalize the code.
llvm-svn: 13415
 | 
| | 
| 
| 
|  | 
llvm-svn: 13400
 | 
| | 
| 
| 
| 
| 
|  | 
This fixes PR332 and ADCE/2004-05-04-UnreachableBlock.llx
llvm-svn: 13349
 | 
| | 
| 
| 
|  | 
llvm-svn: 13341
 | 
| | 
| 
| 
|  | 
llvm-svn: 13340
 | 
| | 
| 
| 
| 
| 
|  | 
which case you'll get a null array and zero passed to the profiling function.
llvm-svn: 13336
 | 
| | 
| 
| 
|  | 
llvm-svn: 13335
 | 
| | 
| 
| 
|  | 
llvm-svn: 13316
 | 
| | 
| 
| 
|  | 
llvm-svn: 13315
 | 
| | 
| 
| 
|  | 
llvm-svn: 13312
 | 
| | 
| 
| 
| 
| 
|  | 
Turning "if (A < B && B < C)" into "if (A < B & B < C)"
llvm-svn: 13311
 | 
| | 
| 
| 
| 
| 
|  | 
missing opportunities for combination.
llvm-svn: 13309
 | 
| | 
| 
| 
| 
| 
|  | 
when replacing them, missing the opportunity to do simplifications
llvm-svn: 13308
 | 
| | 
| 
| 
|  | 
llvm-svn: 13307
 | 
| | 
| 
| 
|  | 
llvm-svn: 13306
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
is only used by a cast, and the casted type is the same size as the original
allocation, it would eliminate the cast by folding it into the allocation.
Unfortunately, it was placing the new allocation instruction right before
the cast, which could pull (for example) alloca instructions into the body
of a function.  This turns statically allocatable allocas into expensive
dynamically allocated allocas, which is bad bad bad.
This fixes the problem by placing the new allocation instruction at the same
place the old one was, duh. :)
llvm-svn: 13289
 | 
| | 
| 
| 
| 
| 
|  | 
patch was graciously contributed by Vladimir Prus.
llvm-svn: 13185
 | 
| | 
| 
| 
|  | 
llvm-svn: 13172
 | 
| | 
| 
| 
| 
| 
|  | 
* Commandline option (for now) controls that flag that is passed in
llvm-svn: 13141
 | 
| | 
| 
| 
| 
| 
| 
|  | 
still room for cleanup, but at least the code modification is out of the
analysis now.
llvm-svn: 13135
 | 
| | 
| 
| 
| 
| 
|  | 
the function instead of isolating it. This also means the condition is reversed.
llvm-svn: 13112
 | 
| | 
| 
| 
| 
| 
| 
|  | 
the Module. The default behavior keeps functionality as before: the chosen
function is the one that remains.
llvm-svn: 13111
 | 
| | 
| 
| 
|  | 
llvm-svn: 13108
 | 
| | 
| 
| 
|  | 
llvm-svn: 13106
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
loop.  This eliminates the extra add from the previous case, but it's
not clear that this will be a performance win overall.  Tommorows test
results will tell. :)
llvm-svn: 13103
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
over its USES.  If it's dead it doesn't have any uses!  :)
Thanks to the fabulous and mysterious Bill Wendling for pointing this out.  :)
llvm-svn: 13102
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
types in them.  Instead of creating an induction variable for all types, it
creates a single induction variable and casts to the other sizes.  This generates
this code:
no_exit:                ; preds = %entry, %no_exit
        %indvar = phi uint [ %indvar.next, %no_exit ], [ 0, %entry ]            ; <uint> [#uses=4]
***     %j.0.0 = cast uint %indvar to short             ; <short> [#uses=1]
        %indvar = cast uint %indvar to int              ; <int> [#uses=1]
        %tmp.7 = getelementptr short* %P, uint %indvar          ; <short*> [#uses=1]
        store short %j.0.0, short* %tmp.7
        %inc.0 = add int %indvar, 1             ; <int> [#uses=2]
        %tmp.2 = setlt int %inc.0, %N           ; <bool> [#uses=1]
        %indvar.next = add uint %indvar, 1              ; <uint> [#uses=1]
        br bool %tmp.2, label %no_exit, label %loopexit
instead of:
no_exit:                ; preds = %entry, %no_exit
        %indvar = phi ushort [ %indvar.next, %no_exit ], [ 0, %entry ]          ; <ushort> [#uses=2]
***     %indvar = phi uint [ %indvar.next, %no_exit ], [ 0, %entry ]            ; <uint> [#uses=3]
        %indvar = cast uint %indvar to int              ; <int> [#uses=1]
        %indvar = cast ushort %indvar to short          ; <short> [#uses=1]
        %tmp.7 = getelementptr short* %P, uint %indvar          ; <short*> [#uses=1]
        store short %indvar, short* %tmp.7
        %inc.0 = add int %indvar, 1             ; <int> [#uses=2]
        %tmp.2 = setlt int %inc.0, %N           ; <bool> [#uses=1]
        %indvar.next = add uint %indvar, 1
***     %indvar.next = add ushort %indvar, 1
        br bool %tmp.2, label %no_exit, label %loopexit
This is an improvement in register pressure, but probably doesn't happen that
often.
The more important fix will be to get rid of the redundant add.
llvm-svn: 13101
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
ilists :)
Eventually it would be nice if CallGraph maintained an ilist of CallGraphNode's instead
of a vector of pointers to them, but today is not that day.
llvm-svn: 13100
 | 
| | 
| 
| 
|  | 
llvm-svn: 13091
 | 
| | 
| 
| 
|  | 
llvm-svn: 13089
 | 
| | 
| 
| 
| 
| 
|  | 
is done, which avoids invalidating iterators in the SCC traversal routines
llvm-svn: 13088
 | 
| | 
| 
| 
|  | 
llvm-svn: 13081
 | 
| | 
| 
| 
|  | 
llvm-svn: 13080
 | 
| | 
| 
| 
| 
| 
|  | 
but it's a start, and seems to do it's basic job.
llvm-svn: 13068
 | 
| | 
| 
| 
|  | 
llvm-svn: 13057
 | 
| | 
| 
| 
|  | 
llvm-svn: 13051
 | 
| | 
| 
| 
|  | 
llvm-svn: 13048
 | 
| | 
| 
| 
| 
| 
|  | 
on demand.
llvm-svn: 13046
 | 
| | 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
|  | 
of hardcoded
llvm-svn: 13025
 |