This reverts commit ef388334ee5a3584255b9ef5b3fefdb244fa3fd7.
The referenced issue violates the spec for finite-only math only by
using a return value for a constant infinity. If the interpretation
is results and arguments cannot violate nofpclass, then any
std::numeric_limits<T>::infinity() result is invalid under
-ffinite-math-only. Without this interpretation the utility of
nofpclass is slashed.
The assertion in #80597 failed when we were trying to compute known bits
of a value in an unreachable BB.
859b09da08/llvm/lib/Transforms/InstCombine/InstCombineSimplifyDemanded.cpp (L749-L810)
In this case, `SignBits` is 30 (deduced from instr info), but `Known` is
`10000101010111010011110101000?0?00000000000000000000000000000000`
(deduced from dom cond). Setting high bits of `lshr Known, 1` will lead
to conflict.
This patch masks out high bits of `Known.Zero` to address this problem.
Fixes#80597.
In line with updated shufflevector semantics, this represents the
poison elements rather than undef elements now. This commit is a
pure rename, without any logic changes.
Do not poison `undef` demanded elements in `SimplifyDemandedVectorElts`.
A miscompilation issue has been addressed with refined checking.
Proofs: https://alive2.llvm.org/ce/z/WA5oD5.
Change (add x, c) to (xor x, c) iff c is constant and c equals the top bit of the demanded bits.
Alive2: https://alive2.llvm.org/ce/z/DKmkwF
---------
Signed-off-by: Peter Han <fujun.han@iluvatar.com>
Co-authored-by: Peter Han <fujun.han@iluvatar.com>
It looks like my original patch got caught up in
ef388334ee5a3584255b9ef5b3fefdb244fa3fd7 that was reverting a different
patch.
Original message:
Retain name for SExt->ZExt and AShr->LShr. Previously SExt->ZExt copied
the name with a numeric suffix. AShr->LShr dropped it.
The disjoint flag was recently added to IR in #72583
We already set it when we turn an add into an or. This patch sets it on Ors that weren't converted from an Add.
I'm occasionally using this to find cases where computeKnownBits()
and SimplifyDemandedBits() went out of sync.
This option is not enabled by default (even under EXPENSIVE_CHECKS)
because it has a number of known failures in our tests. The reason
for this failures is that computeKnownBits() performs recursive
queries using the original context instruction, while
SimplifyDemandedBits() uses the current instruction. This is
something we can improve, but using the original context wouldn't
always be safe in this context (when non-speculatable instructions
are involved).
In practice this is already true, and having this as an explicit
guarantee is useful for #72912. I don't think there is any good
reason why we would want to produce incorrect KnownBits results
for non-demanded bits.
We were using this helper in single-use demanded bits but not
multi-use demanded bits.
This fixes an assertion failure when asserting consistency between
computeKnownBits() and SimplifyDemandedBits().
This flag indicates that every bit is known to be zero in at least one
of the inputs. This allows the Or to be treated as an Add since there is
no possibility of a carry from any bit.
If the flag is present and this property does not hold, the result is
poison.
This makes it easier to reverse the InstCombine transform that turns Add
into Or.
This is inspired by a comment here
https://github.com/llvm/llvm-project/pull/71955#discussion_r1391614578
Discourse thread
https://discourse.llvm.org/t/rfc-add-or-disjoint-flag/75036
The complex set of type checks in this code reduces down to
"always return nullptr". Drop the code to use the default
implementation instead, which will just compute the KnownBits
for the bitcast.
zext nneg was recently added to the IR in #67982. This patch teaches
demanded bits and known bits about the semantics of the instruction, and
adds a couple of test cases to illustrate basic functionality.
Demanded bit simplification for lshr/ashr will currently demand the low
bits if the exact flag is set. This is because these bits must be zero
to satisfy the flag.
However, this means that our demanded bits simplification is worse for
lshr/ashr exact than it is for plain lshr/ashr, which is generally not
desirable.
Instead, drop the exact flag if a demanded bits simplification of the
operand succeeds, which may no longer satisfy the exact flag.
This matches what we do for the exact flag on udiv, as well as the
nuw/nsw flags on add/sub/mul.
This reverts commit b5743d4798b250506965e07ebab806a3c2d767cc.
This causes some minor compile-time impact. Revert for now, better
to do the change more gradually.
This is the floating-point analog of SimplifyDemandedBits. If we know
the edge cases are assumed impossible in uses, it's possible to prune
upstream edge case handling.
Start by only using this on returns in functions with nofpclass
returns (where I'm surprised there are no other combines), but this
can be extended to include any other nofpclass use or FPMathOperator
with flags.
Partially addresses issue #64870https://reviews.llvm.org/D158648
As per my proposal for how to eliminate debug intrinsics [0], for various
places in InstCombine prefer to insert using an instruction iterator rather
than an instruction pointer. This is so that we can eventually pass more
information in the iterator class. These call-sites where I've changed the
spelling are those that necessary to build a stage2clang to produce an
identical binary in the coming no-debug-intrinsics mode.
[0] https://discourse.llvm.org/t/rfc-instruction-api-changes-needed-to-eliminate-debug-intrinsics-from-ir/68939
Differential Revision: https://reviews.llvm.org/D152543
Bug #63699 shows a hang on arm in instcombine because we do not
propagate known bits for fshl/fshr rotates. We perform the propagation
and add regression test.
Differential Revision: https://reviews.llvm.org/D155307
This fixes the largest remaining discrepancy between results of
computeKnownBits() and SimplifyDemandedBits(). We only care about
the multi-use case here, because the assume necessarily introduces
an extra use.
Disable conversion of funnel shifts (fshl/fshr) into rotates
unless one of the operands is known to be a constant value.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D150670
I suspect that this case is not actually reachable in practice
(because it gets folded away by other code before), but if we do
reach it, we should return poison, not undef.
Otherwise the result will always be unknown anyway. This fixes one
of the last inconsistencies in results between computeKnownBits()
and SimplifyDemandedBits().
We were failing to set the known bits for add/sub in the multi-use
case, resulting in odd behavioral differences depending on the
number of uses. Noticed while adding a consistency assertion.
The test changes are essentially a revert to the state before
d6498ab. These changes are not really desirable, but if we don't
want them, that needs to be handled as part of the heuristic for
demanded constant shrinking, not by artifically suppressing the
known bits in one specific case.
This provides more precise results than the ad-hoc implementation.
Noticed while trying to add a consistency assertion.
To be honest I'm not sure why this code exists at all -- the
recursive calls are done with all bits demanded, so this should
be equivalent to just using the default case.
For the case of a non-constant operand, fall back to
computeKnownBits() rather than trying to reimplement logic.
Found while testing a consistency assertion for both functions.
