| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Only emit one PHI node for IV uses with identical bases and strides (after
moving foldable immediates to the load/store instruction).
This implements LoopStrengthReduce/dont_insert_redundant_ops.ll, allowing
us to generate this PPC code for test1:
or r30, r3, r3
.LBB_test1_1: ; Loop
li r2, 0
stw r2, 0(r30)
stw r2, 4(r30)
bl L_pred$stub
addi r30, r30, 8
cmplwi cr0, r3, 0
bne .LBB_test1_1 ; Loop
instead of this code:
or r30, r3, r3
or r29, r3, r3
.LBB_test1_1: ; Loop
li r2, 0
stw r2, 0(r29)
stw r2, 4(r30)
bl L_pred$stub
addi r30, r30, 8 ;; Two iv's with step of 8
addi r29, r29, 8
cmplwi cr0, r3, 0
bne .LBB_test1_1 ; Loop
llvm-svn: 22635
|
| |
|
|
|
|
|
| |
unify some parallel vectors and get field names more descriptive than
"first" and "second". This isn't lisp afterall :)
llvm-svn: 22633
|
| |
|
|
|
|
|
|
|
| |
map from instruction* to SCEVHandles. When we delete instructions, we have
to tell it about it. We would run into nasty cases where new instructions
were reallocated at old instruction addresses and get the old map values.
Bad bad bad :(
llvm-svn: 22632
|
| |
|
|
|
|
| |
Transforms/LowerInvoke/2005-08-03-InvokeWithPHIUse.ll
llvm-svn: 22628
|
| |
|
|
|
|
| |
fixes PR612 and Transforms/LowerInvoke/2005-08-03-InvokeWithPHI.ll
llvm-svn: 22626
|
| |
|
|
|
|
| |
occurred while bugpointing another testcase
llvm-svn: 22621
|
| |
|
|
|
|
|
|
| |
Transforms/SimplifyCFG/2005-08-01-PHIUpdateFail.ll
the right way
llvm-svn: 22615
|
| |
|
|
| |
llvm-svn: 22613
|
| |
|
|
|
|
| |
function with no side-effects
llvm-svn: 22612
|
| |
|
|
| |
llvm-svn: 22611
|
| |
|
|
|
|
| |
some duplicated code
llvm-svn: 22610
|
| |
|
|
|
|
| |
call it from the only place it is live. No functionality changes.
llvm-svn: 22609
|
| |
|
|
|
|
|
|
|
| |
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050801/027345.html
This breaks real programs and only fixes an obscure regression testcase. A
real fix is in development.
llvm-svn: 22606
|
| |
|
|
| |
llvm-svn: 22605
|
| |
|
|
|
|
| |
Patch contributed by Jim Laskey!
llvm-svn: 22592
|
| |
|
|
| |
llvm-svn: 22586
|
| |
|
|
|
|
|
|
| |
consideration the case where a reference in an unreachable block could
occur. This fixes Transforms/SimplifyCFG/2005-08-01-PHIUpdateFail.ll,
something I ran into while bugpoint'ing another pass.
llvm-svn: 22584
|
| |
|
|
| |
llvm-svn: 22581
|
| |
|
|
| |
llvm-svn: 22580
|
| |
|
|
|
|
|
| |
Make LSR ignore GEP's that have loop variant base values, as we currently
cannot codegen them
llvm-svn: 22576
|
| |
|
|
| |
llvm-svn: 22575
|
| |
|
|
|
|
|
|
|
|
| |
SimplifyLibCalls probably has to be audited to make sure it does not make
this mistake elsewhere. Also, if this code knows that the type will be
unsigned, obviously one arm of this is dead.
Reid, can you take a look into this further?
llvm-svn: 22566
|
| |
|
|
| |
llvm-svn: 22565
|
| |
|
|
| |
llvm-svn: 22564
|
| |
|
|
| |
llvm-svn: 22560
|
| |
|
|
|
|
|
|
| |
target data to decide which loop induction variables to strength reduce
and how to do so. This work is mostly by Chris Lattner, with tweaks by
me to get it working on some of MultiSource.
llvm-svn: 22558
|
| |
|
|
|
|
| |
other passes may use it.
llvm-svn: 22557
|
| |
|
|
| |
llvm-svn: 22523
|
| |
|
|
|
|
| |
is actually dead because of this!
llvm-svn: 22515
|
| |
|
|
|
|
|
|
| |
explained in the comment.
This fixes UnitTests/2003-09-18-BitFieldTest on darwin
llvm-svn: 22483
|
| |
|
|
|
|
| |
as a signed compare. This patch may fix PR597, but is correct in any case.
llvm-svn: 22465
|
| |
|
|
|
|
|
|
|
| |
Because the instcombine has to scan the entire function when it starts up
to begin with, we might as well do it in DFO so we can nuke unreachable code.
This fixes: Transforms/InstCombine/2005-07-07-DeadPHILoop.ll
llvm-svn: 22348
|
| |
|
|
|
|
|
|
| |
The optimization for locally used allocas was not safe for allocas that
were read before they were written. This change disables that optimization
in that case.
llvm-svn: 22318
|
| |
|
|
| |
llvm-svn: 22312
|
| |
|
|
|
|
|
|
|
| |
is a mismatch in their character type pointers (i.e. fprintf() prints an
array of ubytes while fwrite() takes an array of sbytes).
We can probably do better than this (such as casting the ubyte to an
sbyte).
llvm-svn: 22310
|
| |
|
|
| |
llvm-svn: 22277
|
| |
|
|
| |
llvm-svn: 22265
|
| |
|
|
| |
llvm-svn: 22263
|
| |
|
|
| |
llvm-svn: 22254
|
| |
|
|
|
|
| |
not casting to the correct type.
llvm-svn: 22250
|
| |
|
|
|
|
| |
GCC 4.0.0 compiler (sometimes incorrectly) warns about under release build.
llvm-svn: 22249
|
| |
|
|
|
|
|
| |
It is actually always true. This fixes PR586 and
Transforms/InstCombine/2005-06-16-SetCCOrSetCCMiscompile.ll
llvm-svn: 22236
|
| |
|
|
|
|
| |
Transforms/InstCombine/2005-06-16-RangeCrash.ll
llvm-svn: 22234
|
| |
|
|
|
|
| |
This fixes PR584 and Transforms/SimplifyCFG/2005-06-16-PHICrash.ll
llvm-svn: 22232
|
| |
|
|
| |
llvm-svn: 22230
|
| |
|
|
| |
llvm-svn: 22227
|
| |
|
|
| |
llvm-svn: 22225
|
| |
|
|
|
|
| |
is always ubyte, get the type being shifted). This unbreaks espresso
llvm-svn: 22224
|
| |
|
|
| |
llvm-svn: 22223
|
| |
|
|
|
|
| |
BB iterator. This fixes Transforms/IndVarsSimplify/2005-06-15-InstMoveCrash.ll
llvm-svn: 22221
|