| Age | Commit message (Collapse) | Author |
|
still having predecessor, if it is part of a self-loop.
Because of this, we cannot use the Simplify* APIs, as they can assert-fail on unreachable code. Since it's not easy to determine
if a given threading will cause a block to become unreachable, simply defer simplifying simplification to later InstCombine and/or
DCE passes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115082 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Usually we wouldn't do this anyway because llvm_fenv_testexcept would return an
exception, but we have seen some cases where neither errno nor fenv detect an
exception on arm-linux.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114893 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
post-dominated the block it was being hoisted to.
Splitting critical edges at the merge point only addressed part of the issue; it is also possible for non-post-domination
to occur when the path from the load to the merge has branches in it. Unfortunately, full anticipation analysis is
time-consuming, so for now approximate it. This is strictly more conservative than real anticipation, so we will miss
some cases that real PRE would allow, but we also no longer insert loads into paths where they didn't exist before. :-)
This is a very slight net positive on SPEC for me (0.5% on average). Most of the benchmarks are largely unaffected, but
when it pays off it pays off decently: 181.mcf improves by 4.5% on my machine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114785 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
http://google1.osuosl.org:8011/builders/llvm-arm-linux
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114755 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114241 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114202 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
"inexact" result.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114198 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
so that it detects errors on platforms where libm doesn't set errno.
It's still subject to host libm details though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114148 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114106 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ConstantExpr's, for LVI to end up trying to merge
a Constant into a ConstantRange. Handle this conservatively for now, rather than asserting. The testcase is
more complex that I would like, but the manifestation of the problem is sensitive to iteration orders and the state of the
LVI cache, and I have not been able to reproduce it with manually constructed or simplified cases.
Fixes PR8162.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114103 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
simplification to try
to replace an instruction with itself. Add a predicate to the simplifier to prevent this case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114097 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
attribute(used).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113911 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113855 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
deleted. Fix this by doing the copyValue's before we delete stuff!
The testcase only repros the problem on my system with valgrind.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113820 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113770 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instcombine transforms
to expose greater opportunities for store narrowing in codegen. This patch fixes a potential
infinite loop in instcombine caused by one of the introduced transforms being overly aggressive.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113763 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
on to Owen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113720 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of the and's mask.
This can result in increased opportunities for store narrowing in code generation. Update a number of
tests for this change. This fixes <rdar://problem/8285027>.
Additionally, because this inverts the order of ors and ands, some patterns for optimizing or-of-and-of-or
no longer fire in instances where they did originally. Add a simple transform which recaptures most of these
opportunities: if we have an or-of-constant-or and have failed to fold away the inner or, commute the order
of the two ors, to give the non-constant or a chance for simplification instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113679 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Reassociate does this but it doesn't catch all cases (e.g. if the operands are i1).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113651 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
cannot be unrolled. After some discussion,
there seems to be a better way to achieve the same effect.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113528 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
contains a call, lower the
unrolling threshold to the optimize-for-size threshold. Basically, for loops containing calls, unrolling
can still be profitable as long as the loop is REALLY small.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113439 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
single test. Patch by Dirk Steinke!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113423 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
turning (fptrunc (sqrt (fpext x))) -> (sqrtf x) is great, but we have
to delete the original sqrt as well. Not doing so causes us to do
two sqrt's when building with -fmath-errno (the default on linux).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113260 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113257 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113146 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in the duplicated block instead of duplicating them.
Duplicating them into the end of the loop and the preheader
means that we got a phi node in the header of the loop,
which prevented LICM from hoisting them. GVN would
usually come around later and merge the duplicated
instructions so we'd get reasonable output... except that
anything dependent on the shoulda-been-hoisted value can't
be hoisted. In PR5319 (which this fixes), a memory value
didn't get promoted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113134 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113109 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
into an inner loop, as the new loop iteration may differ substantially.
This fixes PR8078.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113057 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
location is being re-stored to the memory location. We would get
a dangling pointer from the SSAUpdate data structure and miss a
use. This fixes PR8068
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113042 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113025 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
global when it
is provable that they're equivalent. This fixes PR4855.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112994 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112987 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112971 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112892 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112889 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112878 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112851 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LVI lattice, undef and the full set ConstantRange should not
be treated as equivalent.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112843 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and there seems to be no reason not to.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112812 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112763 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
infinite loops or exits will eventually exit. This fixes PR5373.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112745 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112724 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
on llvmdev: SRoA is introducing MMX datatypes like <1 x i64>,
which then cause random problems because the X86 backend is
producing mmx stuff without inserting proper emms calls.
In the short term, force off MMX datatypes. In the long term,
the X86 backend should not select generic vector types to MMX
registers. This is being worked on, but won't be done in time
for 2.8. rdar://8380055
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112696 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112695 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instead of hoisting them, just fold them away. This occurs in the
testcase for PR8041, for example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112669 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112635 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112621 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112617 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112615 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112613 91177308-0d34-0410-b5e6-96231b3b80d8
|