| Commit message (Collapse) | Author | Age | Files | Lines | 
| ... |  | 
| | 
| 
| 
|  | 
llvm-svn: 20408
 | 
| | 
| 
| 
|  | 
llvm-svn: 20407
 | 
| | 
| 
| 
| 
| 
|  | 
Loop Strength Reduction.
llvm-svn: 20399
 | 
| | 
| 
| 
|  | 
llvm-svn: 20397
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
explanation from IRC:
	|sabre|	I think it's an order of evaluation thing
	|sabre|	for me, the RHS of the assignment is evaluated first
	|sabre|	getTypeDescription checks to see if ConcreteTypeDescription[Ty] contains anything
	|sabre|	since it doesn't, it computes and returns the value
	|sabre|	this gets put into the map.
	|sabre|	For you, the LHS is evaluated first.
	|sabre|	Map[Ty] (aka ConcreteTypeDescriptions[Ty]) inserts an empty string into the map, returning a reference
	|sabre|	getTypeDesc then sees the empty string in the map
	|sabre|	and returns it
	|sabre|	bork :)
llvm-svn: 20394
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
* Loop invariant code does not dominate the loop header, but rather
    the end of the loop preheader.
  * The base for a reduced GEP isn't a constant unless all of its
    operands (preceding the induction variable) are constant.
  * Allow induction variable elimination for the simple case after all.
Also made changes recommended by Chris for properly deleting
instructions.
llvm-svn: 20383
 | 
| | 
| 
| 
|  | 
llvm-svn: 20382
 | 
| | 
| 
| 
|  | 
llvm-svn: 20380
 | 
| | 
| 
| 
| 
| 
|  | 
Justin Wick!
llvm-svn: 20378
 | 
| | 
| 
| 
|  | 
llvm-svn: 20377
 | 
| | 
| 
| 
|  | 
llvm-svn: 20376
 | 
| | 
| 
| 
|  | 
llvm-svn: 20375
 | 
| | 
| 
| 
|  | 
llvm-svn: 20372
 | 
| | 
| 
| 
| 
| 
| 
|  | 
for reasons explained in the comments, I also deactivated this code as it needs
more thought.
llvm-svn: 20367
 | 
| | 
| 
| 
|  | 
llvm-svn: 20360
 | 
| | 
| 
| 
| 
| 
|  | 
prime time.
llvm-svn: 20358
 | 
| | 
| 
| 
|  | 
llvm-svn: 20354
 | 
| | 
| 
| 
|  | 
llvm-svn: 20352
 | 
| | 
| 
| 
|  | 
llvm-svn: 20343
 | 
| | 
| 
| 
|  | 
llvm-svn: 20342
 | 
| | 
| 
| 
|  | 
llvm-svn: 20340
 | 
| | 
| 
| 
|  | 
llvm-svn: 20339
 | 
| | 
| 
| 
| 
| 
| 
|  | 
bytecode file members or not.
Patch Contributed By Adam Treat
llvm-svn: 20338
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
If we fold three constants together (c1+c2+c3), make sure to keep
LHSC updated, instead of reusing (in this case), the 1 instead of the
partial sum.
llvm-svn: 20337
 | 
| | 
| 
| 
|  | 
llvm-svn: 20334
 | 
| | 
| 
| 
| 
| 
|  | 
further pecimise the FP instructions
llvm-svn: 20332
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Actually teach dsa about select instructions.  This doesn't affect the
graph in any way other than not setting a spurious U marker on pointer
nodes that are selected.
llvm-svn: 20324
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
X = gep null, ...
Used to not create a scalar map entry for X, which caused clients to barf.
This is bad.
llvm-svn: 20316
 | 
| | 
| 
| 
|  | 
llvm-svn: 20308
 | 
| | 
| 
| 
|  | 
llvm-svn: 20306
 | 
| | 
| 
| 
| 
| 
|  | 
reporting the problem and exiting.
llvm-svn: 20302
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
This does a simple form of "jump threading", which eliminates CFG edges that
are provably dead.  This triggers 90 times in the external tests, and
eliminating CFG edges is always always a good thing! :)
llvm-svn: 20300
 | 
| | 
| 
| 
|  | 
llvm-svn: 20298
 | 
| | 
| 
| 
|  | 
llvm-svn: 20297
 | 
| | 
| 
| 
|  | 
llvm-svn: 20296
 | 
| | 
| 
| 
|  | 
llvm-svn: 20295
 | 
| | 
| 
| 
|  | 
llvm-svn: 20293
 | 
| | 
| 
| 
| 
| 
|  | 
actually doing modulo scheduling! :)
llvm-svn: 20292
 | 
| | 
| 
| 
|  | 
llvm-svn: 20290
 | 
| | 
| 
| 
|  | 
llvm-svn: 20289
 | 
| | 
| 
| 
|  | 
llvm-svn: 20288
 | 
| | 
| 
| 
| 
| 
|  | 
this reduces the time for -simplifycfg in a debug build from 106s to 14.82s
llvm-svn: 20286
 | 
| | 
| 
| 
|  | 
llvm-svn: 20284
 | 
| | 
| 
| 
| 
| 
|  | 
information.
llvm-svn: 20280
 | 
| | 
| 
| 
|  | 
llvm-svn: 20278
 | 
| | 
| 
| 
|  | 
llvm-svn: 20277
 | 
| | 
| 
| 
|  | 
llvm-svn: 20276
 | 
| | 
| 
| 
|  | 
llvm-svn: 20274
 | 
| | 
| 
| 
|  | 
llvm-svn: 20273
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Changing 'op' here caused us to not enter the store into a map, causing
reemission of the code!!  In practice, a simple loop like this:
no_exit:                ; preds = %no_exit, %entry
        %indvar = phi uint [ %indvar.next, %no_exit ], [ 0, %entry ]            ; <uint> [#uses=3]
        %tmp.4 = getelementptr "complex long double"* %P, uint %indvar, uint 0          ; <double*> [#uses=1]
        store double 0.000000e+00, double* %tmp.4
        %indvar.next = add uint %indvar, 1              ; <uint> [#uses=2]
        %exitcond = seteq uint %indvar.next, %N         ; <bool> [#uses=1]
        br bool %exitcond, label %return, label %no_exit
was being code gen'd to:
.LBBtest_1:     # no_exit
        movl %edx, %esi
        shll $4, %esi
        movl $0, 4(%eax,%esi)
        movl $0, (%eax,%esi)
        incl %edx
        movl $0, (%eax,%esi)
        movl $0, 4(%eax,%esi)
        cmpl %ecx, %edx
        jne .LBBtest_1  # no_exit
Note that we are doing 4 32-bit stores instead of 2.  Now we generate:
.LBBtest_1:     # no_exit
        movl %edx, %esi
        incl %esi
        shll $4, %edx
        movl $0, (%eax,%edx)
        movl $0, 4(%eax,%edx)
        cmpl %ecx, %esi
        movl %esi, %edx
        jne .LBBtest_1  # no_exit
This is much happier, though it would be even better if the increment of ESI
was scheduled after the compare :-/
llvm-svn: 20265
 |