FindInsertedValue, it now performs a number of simple transformations that
should result in the same effect when applied iteratively.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53673 91177308-0d34-0410-b5e6-96231b3b80d8
return value as a whole in deadargelim is really not needed now that we simply
rebuild the old return value and actually prevents some canonicalization from
taking place.
This revert stops deadargelim from changing {i32} into i32 for now, but I'll
fix that next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53609 91177308-0d34-0410-b5e6-96231b3b80d8
return values that are still (partially) live. Instead of updating all uses of
a call instruction after removing some elements, it now just rebuilds the
original struct (With undef gaps where the unused values were) and leaves it to
instcombine to clean this up.
The added testcase still fails currently, but this is due to instcombine which
isn't good enough yet. I will fix that part next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53608 91177308-0d34-0410-b5e6-96231b3b80d8
only the liveness of partial return values (for functions returning a struct).
This is more explicit to prevent unwanted changes in the return value.
In particular, deadargelim now canonicalizes a function returning {i32} to
returning i32 and {} to void, if the struct returned is not used in its
entirety, but only the single element is used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53606 91177308-0d34-0410-b5e6-96231b3b80d8
and return values live for those functions. This doesn't change anything yet,
but prepares for the coming commits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53601 91177308-0d34-0410-b5e6-96231b3b80d8
the min/max values for an integer type, compare against the min/max
values we can prove contain the input. This might be a tighter bound,
so this is general goodness.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53446 91177308-0d34-0410-b5e6-96231b3b80d8
was using the algorithm for folding unsigned comparisons which is
completely wrong. This has been broken since the signless types change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53444 91177308-0d34-0410-b5e6-96231b3b80d8
This cause a regression in InstCombine/JavaCompare, which was doing the right
thing on accident. To handle the missed case, generalize the comparisons based
on masked bits a little bit to handle comparisons against the max value. For
example, we can now xform (slt i32 (and X, 4), 4) -> (setne i32 (and X, 4), 4)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53443 91177308-0d34-0410-b5e6-96231b3b80d8
Rewrite the DeadArgumentElimination pass, to use a more explicit tracking of
dependencies between return values and/or arguments. Also make the handling of
arguments and return values the same.
The pass now looks properly inside returned structs, but only at the first
level (ie, not inside nested structs).
This version fixed a few more bugs and was cleaned up a bit. It now passes all
of LLVM's testing, and should still pass SPEC2006. There is still a minor bug
with regard to returning nested structs. Since there is currently nothing that
emits such IR, I will fix that in a seperate commit (partly because it requires
a non-trivial fix).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53400 91177308-0d34-0410-b5e6-96231b3b80d8
into phis. This is actually the same bug as PR2262 /
2008-04-29-VolatileLoadDontMerge.ll, but I missed checking the first
predecessor for multiple successors. Testcase here:
InstCombine/2008-07-08-VolatileLoadMerge.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53240 91177308-0d34-0410-b5e6-96231b3b80d8
1. LSR runOnLoop is always returning false regardless if any transformation is made.
2. AddUsersIfInteresting can create new instructions that are added to DeadInsts. But there is a later early exit which prevents them from being freed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53193 91177308-0d34-0410-b5e6-96231b3b80d8
Also, move large sets and vectors out of instance variables and onto the stack,
and give them more reasonable sizes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53044 91177308-0d34-0410-b5e6-96231b3b80d8
Move GetConstantStringInfo to lib/Analysis. Remove
string output routine from Constant. Update all
callers. Change debug intrinsic api slightly to
accomodate move of routine, these now return values
instead of strings.
This unbreaks llvm-gcc bootstrap.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52884 91177308-0d34-0410-b5e6-96231b3b80d8
string output routine from Constant. Update all
callers. Change debug intrinsic api slightly to
accomodate move of routine, these now return values
instead of strings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52748 91177308-0d34-0410-b5e6-96231b3b80d8
in the presence of out-of-loop users of in-loop values and the trip
count is not a known multiple of the unroll count, and to be a bit
simpler overall. This fixes PR2253.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52645 91177308-0d34-0410-b5e6-96231b3b80d8
instance variables so they can be allocated just once, and reuse the worklist
as the dead list as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52618 91177308-0d34-0410-b5e6-96231b3b80d8
structures. Its default threshold is to promote things that are
smaller than 128 bytes, which is sane. However, it is not sane
to do this for things that turn into 128 *registers*. Add a cap
on the number of registers introduced, defaulting to 128/4=32.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52611 91177308-0d34-0410-b5e6-96231b3b80d8
DeadArgumentElimination and assert that the function type does not change if
nothing was changed. This should catch subtle changes in function type that are
not intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52536 91177308-0d34-0410-b5e6-96231b3b80d8
This is a fixed version that no longer uses multimap::equal_range, which
resulted in a pointer invalidation problem.
Also, DAE::InspectedFunctions was not really necessary, so it got removed.
Lastly, this version no longer applies the extra arg hack on functions who did
not have any arguments to start with.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52532 91177308-0d34-0410-b5e6-96231b3b80d8
GVN expects that all inputs which to an instruction fall somewhere in the value
hierarchy, which isn't true for these.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52496 91177308-0d34-0410-b5e6-96231b3b80d8
dependencies between return values and/or arguments. Also make the handling of
arguments and return values the same.
The pass now looks properly inside returned structs, but only at the first
level (ie, not inside nested structs).
Also add a testcase for testing various variations of (multiple) dead rerturn
values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52459 91177308-0d34-0410-b5e6-96231b3b80d8
time. Sorry for the trouble!
This time, also add a testcase, which I should have done in the first place...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52455 91177308-0d34-0410-b5e6-96231b3b80d8
speaking these are not constant values. However, when a function always returns
one of its arguments, then from the point of view of each caller the return
value is constant (or at least a known value) and can be replaced.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52397 91177308-0d34-0410-b5e6-96231b3b80d8
individually.
Also learn IPConstProp how returning first class aggregates work, in addition
to old style multiple return instructions.
Modify the return-constants testscase to confirm this behaviour.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52396 91177308-0d34-0410-b5e6-96231b3b80d8
when changing the stride of a comparison so that it's slightly
more precise, by having it scan the instruction list to determine
if there is a use of the condition after the point where the
condition will be inserted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52371 91177308-0d34-0410-b5e6-96231b3b80d8
I'm at it, rename it to FindInsertedValue.
The only functional change is that newly created instructions are no longer
added to instcombine's worklist, but that is not really necessary anyway (and
I'll commit some improvements next that will completely remove the need).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52315 91177308-0d34-0410-b5e6-96231b3b80d8
of apint codegen failure is the DAG combiner doing
the wrong thing because it was comparing MVT's using
< rather than comparing the number of bits. Removing
the < method makes this mistake impossible to commit.
Instead, add helper methods for comparing bits and use
them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52098 91177308-0d34-0410-b5e6-96231b3b80d8
and better control the abstraction. Rename the type
to MVT. To update out-of-tree patches, the main
thing to do is to rename MVT::ValueType to MVT, and
rewrite expressions like MVT::getSizeInBits(VT) in
the form VT.getSizeInBits(). Use VT.getSimpleVT()
to extract a MVT::SimpleValueType for use in switch
statements (you will get an assert failure if VT is
an extended value type - these shouldn't exist after
type legalization).
This results in a small speedup of codegen and no
new testsuite failures (x86-64 linux).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52044 91177308-0d34-0410-b5e6-96231b3b80d8
crash the opt. Just fix this.
Test case in llvm/test/Transforms/InstCombine/2008-06-05-ashr-crash.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52003 91177308-0d34-0410-b5e6-96231b3b80d8
work and how to replace them into individual values. Also, when trying to
replace an aggregrate that is used by load or store with a single (large)
integer, don't crash (but don't replace the aggregrate either).
Also adds a testcase for both structs and arrays.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51997 91177308-0d34-0410-b5e6-96231b3b80d8
are the same as in unpacked structs, only field
positions differ. This only matters for structs
containing x86 long double or an apint; it may
cause backwards compatibility problems if someone
has bitcode containing a packed struct with a
field of one of those types.
The issue is that only 10 bytes are needed to
hold an x86 long double: the store size is 10
bytes, but the ABI size is 12 or 16 bytes (linux/
darwin) which comes from rounding the store size
up by the alignment. Because it seemed silly not
to pack an x86 long double into 10 bytes in a
packed struct, this is what was done. I now
think this was a mistake. Reserving the ABI size
for an x86 long double field even in a packed
struct makes things more uniform: the ABI size is
now always used when reserving space for a type.
This means that developers are less likely to
make mistakes. It also makes life easier for the
CBE which otherwise could not represent all LLVM
packed structs (PR2402).
Front-end people might need to adjust the way
they create LLVM structs - see following change
to llvm-gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51928 91177308-0d34-0410-b5e6-96231b3b80d8
out of instcombine into a new file in libanalysis. This also teaches
ComputeNumSignBits about the number of sign bits in a constantint.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51863 91177308-0d34-0410-b5e6-96231b3b80d8
the conditions for performing the transform when only the
function declaration is available: no longer allow turning
i32 into i64 for example. Only allow changing between
pointer types, and between pointer types and integers of
the same size. For return values ptr -> intptr was already
allowed; I added ptr -> ptr and intptr -> ptr while there.
As shown by a recent objc testcase, changing the way
parameters/return values are passed can be fatal when calling
code written in assembler that directly manipulates call
arguments and return values unless the transform has no
impact on the way they are passed at the codegen level.
While it is possible to imagine an ABI that treats integers
of pointer size differently to pointers, I don't think LLVM
supports any so the transform should now be safe while still
being useful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51834 91177308-0d34-0410-b5e6-96231b3b80d8
the one case that ADCE catches that normal DCE doesn't: non-induction variable
loop computations.
This implementation handles this problem without using postdominators.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51668 91177308-0d34-0410-b5e6-96231b3b80d8
the set of nodes. Fix makeEqual to handle this by creating the new node first
then iterating across them second.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51573 91177308-0d34-0410-b5e6-96231b3b80d8
the section or the visibility from one global
value to another: copyAttributesFrom. This is
particularly useful for duplicating functions:
previously this was done by explicitly copying
each attribute in turn at each place where a
new function was created out of an old one, with
the result that obscure attributes were regularly
forgotten (like the collector or the section).
Hopefully now everything is uniform and nothing
is forgotten.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51567 91177308-0d34-0410-b5e6-96231b3b80d8
Analysis/ConstantFolding to fold ConstantExpr's, then make instcombine use it
to try to use targetdata to fold constant expressions on void instructions.
Also extend the icmp(inttoptr, inttoptr) folding to handle the case where
int size != ptr size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51559 91177308-0d34-0410-b5e6-96231b3b80d8
The SimplifyCFG pass looks at basic blocks that contain only phi nodes,
followed by an unconditional branch. In a lot of cases, such a block (BB) can
be merged into their successor (Succ).
This merging is performed by TryToSimplifyUncondBranchFromEmptyBlock. It does
this by taking all phi nodes in the succesor block Succ and expanding them to
include the predecessors of BB. Furthermore, any phi nodes in BB are moved to
Succ and expanded to include the predecessors of Succ as well.
Before attempting this merge, CanPropagatePredecessorsForPHIs checks to see if
all phi nodes can be properly merged. All functional changes are made to
this function, only comments were updated in
TryToSimplifyUncondBranchFromEmptyBlock.
In the original code, CanPropagatePredecessorsForPHIs looks quite convoluted
and more like stack of checks added to handle different kinds of situations
than a comprehensive check. In particular the first check in the function did
some value checking for the case that BB and Succ have a common predecessor,
while the last check in the function simply rejected all cases where BB and
Succ have a common predecessor. The first check was still useful in the case
that BB did not contain any phi nodes at all, though, so it was not completely
useless.
Now, CanPropagatePredecessorsForPHIs is restructured to to look a lot more
similar to the code that actually performs the merge. Both functions now look
at the same phi nodes in about the same order. Any conflicts (phi nodes with
different values for the same source) that could arise from merging or moving
phi nodes are detected. If no conflicts are found, the merge can happen.
Apart from only restructuring the checks, two main changes in functionality
happened.
Firstly, the old code rejected blocks with common predecessors in most cases.
The new code performs some extra checks so common predecessors can be handled
in a lot of cases. Wherever common predecessors still pose problems, the
blocks are left untouched.
Secondly, the old code rejected the merge when values (phi nodes) from BB were
used in any other place than Succ. However, it does not seem that there is any
situation that would require this check. Even more, this can be proven.
Consider that BB is a block containing of a single phi node "%a" and a branch
to Succ. Now, since the definition of %a will dominate all of its uses, BB
will dominate all blocks that use %a. Furthermore, since the branch from BB to
Succ is unconditional, Succ will also dominate all uses of %a.
Now, assume that one predecessor of Succ is not dominated by BB (and thus not
dominated by Succ). Since at least one use of %a (but in reality all of them)
is reachable from Succ, you could end up at a use of %a without passing
through it's definition in BB (by coming from X through Succ). This is a
contradiction, meaning that our original assumption is wrong. Thus, all
predecessors of Succ must also be dominated by BB (and thus also by Succ).
This means that moving the phi node %a from BB to Succ does not pose any
problems when the two blocks are merged, and any use checks are not needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51478 91177308-0d34-0410-b5e6-96231b3b80d8
and/or to handle more cases (such as this add-sitofp.ll testcase), and
port it to selectiondag's ComputeNumSignBits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51469 91177308-0d34-0410-b5e6-96231b3b80d8
ScalarEvolution::deleteValueFromRecords on it before doing the
replaceAllUsesWith, because ScalarEvolution looks at the instruction's
users to find SCEV references to the instruction's SCEV object in its
internal maps.
Move all of LSR's loop-related state clearing after processing the loop
and before cleaning up dead PHI nodes. This eliminates all of LSR's SCEV
references just before the calls to ScalarEvolution::deleteValueFromRecords
so that when ScalarEvolution drops its own SCEV references, the reference
counts will reach zero and the SCEVs will be deleted immediately.
These changes fix some compiler aborts involving ScalarEvolution holding
onto and reusing SCEV objects for instructions that have been deleted.
No regression test unfortunately; because the symptoms were due to
dangling pointers, reduced testcases ended up being fairly arbitrary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51359 91177308-0d34-0410-b5e6-96231b3b80d8
replaced is a PHI. This prevents it from inserting uses before defs
in the case that it isn't a PHI and it depends on other instructions
later in the block. This fixes the 447.dealII regression on x86-64.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51292 91177308-0d34-0410-b5e6-96231b3b80d8
to accurately represent the integer. This triggers 9 times in 471.omnetpp,
though 8 of those seem to be inlined from the same place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51271 91177308-0d34-0410-b5e6-96231b3b80d8
type and the other operand is a constant into integer comparisons.
This happens surprisingly frequently (e.g. 10 times in 471.omnetpp),
which are things like this:
%tmp8283 = sitofp i32 %tmp82 to double
%tmp1013 = fcmp ult double %tmp8283, 0.0
Clearly comparing tmp82 against i32 0 is cheaper here.
this also triggers 8 times in gobmk, including this one:
%tmp375376 = sitofp i32 %tmp375 to double
%tmp377 = fcmp ogt double %tmp375376, 8.150000e+01
which is comparing an integer against 81.5 :).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51268 91177308-0d34-0410-b5e6-96231b3b80d8
intersecting bits. This triggers all over the place, for example in lencode,
with adds of stuff like:
%tmp580 = mul i32 %tmp579, 2
%tmp582 = and i32 %b8, 1
and
%tmp28 = shl i32 %abs.i, 1
%sign.0 = select i1 %tmp23, i32 1, i32 0
and
%tmp344 = shl i32 %tmp343, 2
%tmp346 = and i32 %tmp96, 3
etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51263 91177308-0d34-0410-b5e6-96231b3b80d8
