Targets the dynamic realignment pattern of `(Ptr + Align - 1) & -Align;`
as implemented by gep then ptrmask.
Specifically, when the pointer already has alignment information,
dynamically realigning it to less than is already known should be a
no-op. Discovered while writing test cases for another patch.
For the zero low bits of a known aligned pointer, adding the gep index
then removing it with a mask is a no-op. Folding the ptrmask effect
entirely into the gep is the ideal result as that unblocks other
optimisations that are not aware of ptrmask.
In some other cases the gep is known to be dead and is removed without
changing the ptrmask.
In the least effective case, this transform creates a new gep with a
rounded-down index and still leaves the ptrmask unchanged. That
simplified gep is still a minor improvement, geps are cheap and ptrmask
occurs in address calculation contexts so I don't think it's worth
special casing to avoid the extra instruction.
A miscompilation issue has been addressed with refined checking.
Shuffle masks operand may be turned into `poison` if this does
not lead to observable changes. This however may not guarantee
binop to binop-of-shuffle replacement to be sound anymore.
Fixes: https://github.com/llvm/llvm-project/issues/82052.
fshl/fshr having first two arguments as same gets lowered to target
specific rotate. But based on the uses, one of the arguments can get
simplified resulting in different arguments performing equivalent
operation.
This patch prevents the simplification of the arguments of lshr/shl if
they are part of fshl pattern.
Closes https://github.com/llvm/llvm-project/pull/73441.
This reverts commit ef388334ee.
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.
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.
It looks like my original patch got caught up in
ef388334ee 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 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.
hanbeom
Jon Chesterfield
Noah Goldstein
Antonio Frighetto
Eikansh Gupta
Matt Arsenault
Yingwei Zheng
Nikita Popov
Fujun HanandPeter Han
Craig Topper
Philip Reames
Leonard Chan
Jonas Hahnfeld
Jeremy Morse
Paulo Matos
David Green