| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 20264
|
| |
|
|
|
|
| |
ANY program that does not have all functions internalized.
llvm-svn: 20258
|
| |
|
|
| |
llvm-svn: 20256
|