(our graphs apparently already fit within the cache on my g5). In any case
this reduces memory usage.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24249 91177308-0d34-0410-b5e6-96231b3b80d8
set and eliminating the need to iterate whenever something is removed (which
can be really slow in some cases). Thx to Jim for pointing out something silly
I was getting stuck on. :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24241 91177308-0d34-0410-b5e6-96231b3b80d8
with the dag combiner. This speeds up espresso by 8%, reaching performance
parity with the dag-combiner-disabled llc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23636 91177308-0d34-0410-b5e6-96231b3b80d8
dead node elim and dag combiner passes where the root is potentially updated.
This fixes a fixme in the dag combiner.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23634 91177308-0d34-0410-b5e6-96231b3b80d8
Though I have done extensive testing, it is possible that this will break
things in configs I can't test. Please let me know if this causes a problem
and I'll fix it ASAP.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23504 91177308-0d34-0410-b5e6-96231b3b80d8
This happens all the time on PPC for bool values, e.g. eliminating a xori
in inverted-bool-compares.ll.
This should be added to the dag combiner as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23403 91177308-0d34-0410-b5e6-96231b3b80d8
select (x < y), 1, 0 -> (x < y) incorrectly: the setcc returns i1 but the
select returned i32. Add the zero extend as needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23301 91177308-0d34-0410-b5e6-96231b3b80d8
we were losing a node, causing an assertion to fail. Now we eagerly delete
discovered CSE's, and provide an optional vector to keep track of these
discovered equivalences.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23255 91177308-0d34-0410-b5e6-96231b3b80d8
from the binary ops map, even if they had multiple results. This latent bug
caused a few failures with the dag isel last night.
To prevent stuff like this from happening in the future, add some really
strict checking to make sure that the CSE maps always match up with reality!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23221 91177308-0d34-0410-b5e6-96231b3b80d8
over to DAGCombiner.cpp
1. Don't assume that SetCC returns i1 when folding (xor (setcc) constant)
2. Don't duplicate code in folding AND with AssertZext that is handled by
MaskedValueIsZero
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23196 91177308-0d34-0410-b5e6-96231b3b80d8
them. This allows for elminination of redundant extends in the entry
blocks of functions on PowerPC.
Add support for i32 x i32 -> i64 multiplies, by recognizing when the inputs
to ISD::MUL in ExpandOp are actually just extended i32 values and not real
i64 values. this allows us to codegen
int mulhs(int a, int b) { return ((long long)a * b) >> 32; }
as:
_mulhs:
mulhw r3, r4, r3
blr
instead of:
_mulhs:
mulhwu r2, r4, r3
srawi r5, r3, 31
mullw r5, r4, r5
add r2, r2, r5
srawi r4, r4, 31
mullw r3, r4, r3
add r3, r2, r3
blr
with a similar improvement on x86.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23147 91177308-0d34-0410-b5e6-96231b3b80d8
putting it into the constant pool. This allows the isel machinery to
create constants that it will end up deciding are not needed, without them
ending up in the resultant function constant pool.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23081 91177308-0d34-0410-b5e6-96231b3b80d8
