This reverts commit 754f3ae65518331b7175d7a9b4a124523ebe6eac.
Unfortunately the change can cause regressions due to dropping flags
from instructions (like nuw,nsw,inbounds), prevent further optimizations
depending on those flags.
A simple example is the IR below, where `inbounds` is dropped with the
patch and the phase-ordering test added in 7c91d82ab912fae8b.
define i1 @test(ptr %base, i64 noundef %len, ptr %p2) {
bb:
%gep = getelementptr inbounds i32, ptr %base, i64 %len
%c.1 = icmp uge ptr %p2, %base
%c.2 = icmp ult ptr %p2, %gep
%select = select i1 %c.1, i1 %c.2, i1 false
ret i1 %select
}
For more discussion, see D149404.
Implement precise nuw/nsw support in the KnownBits implementation,
replacing the rather crude handling in ValueTracking.
Differential Revision: https://reviews.llvm.org/D151208
I removed the conflict check from computeKnownBitsFromShiftOperator()
in D150648 assuming that this is now handled on the KnownBits side.
However, the nsw handling is still inside ValueTracking, so we
still need to handle conflicts there. Restore the check closer to
where it is relevant.
Fixes https://github.com/llvm/llvm-project/issues/62908.
The knownbits implementation covers all the cases previously handled
by `uadd.sat`/`usub.sat` as well some additional ones. We previously
were not handling the `ssub.sat`/`sadd.sat` cases at all.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D150103
For always poison shifts, any KnownBits return value is valid.
Currently we return unknown, but returning zero is generally more
profitable. We had some code in ValueTracking that tried to do this,
but was actually dead code.
Differential Revision: https://reviews.llvm.org/D150648
The only value that can produce -0 is exactly -0, no rounding is involved. If the
denormal mode has flushed denormal inputs, a negative value could produce -0.
The constrained intrinsics do not track the denormal mode, and this is just
generally broken in the current set of FP predicates. The move to computeKnownFPClass
will address some of these issues.
This patch add a new API `impliesPoisonIgnoreFlagsOrMetadatas` which is
the same as `impliesPoison` but ignoring poison generating flags or
metadatas in the process of implying poison and recording these ignored
instructions.
In InstCombineSelect, replacing `impliesPoison` with
`impliesPoisonIgnoreFlagsOrMetadatas` to allow more patterns like
`select i1 %a, i1 %b, i1 false` to be optimized to and/or instructions
by droping the poison generating flags or metadatas.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D149404
For some reason the inliner calls simplifyInstruction with disembodied
instructions. I consider this to be an API defect. Either the instruction
should always be inserted prior to simplification, or we at least
should pass in the new function for the context.
For `X * Y`, if there exists a subset of `X` and subset of `Y` s.t `sX * sY != 0`,
then `X * Y != 0`.
- See first proof: https://alive2.llvm.org/ce/z/28C9CG
- NB: This is why the previous Odd case works.
In knownbits we could exhaustively hunt for such a subset, but
`LSB(X)` and `LSB(Y)` actually works. If `LSB(X) * LSB(Y) != 0`, then
`X * Y != 0`
- See proof: https://alive2.llvm.org/ce/z/p5wWid
In `isKnownNonZero` we can use this as if the `LowestKnownOne(X) *
LowestKnownOne(Y) != 0`, then `X * Y != 0`, and we don't need to try
and other subsets.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D150425
In D148674, the negative condition was weakened to only
checking isKnownNever(fcNegative), instead of cannotBeOrderedLessThanZero().
This avoids a regression when CannotBeOrderedLessThanZero is
replaced with computeKnownFPClass.
Define intersectWith and unionWith as two complementary ways of
combining KnownBits. The names are chosen for consistency with
ConstantRange.
Deprecate commonBits as a synonym for intersectWith.
Differential Revision: https://reviews.llvm.org/D150443
Update code that assumes llvm.canonicalize only handles scalars,
by adding a call to getScalarType().
This is fine, as the intrinsic is trivially vectorizable.
Introduced in D147870, and uncovered by D148065.
Differential Revision: https://reviews.llvm.org/D150556
Seems to be causing a bug in CorrelatedValuePropegation. Reverting
while the issue is investigated.
This reverts commit 6c667abf3294d61e4fbe1238e1755c79f7547f1b.
This broke two lit tests:
LLVM :: Transforms/LoopSimplify/merge-exits.ll
LLVM :: Transforms/PhaseOrdering/X86/vector-reductions.ll
see comment on the code review.
> Differential Revision: https://reviews.llvm.org/D149934
This reverts commit 2ba4cfd56769ab50c9c6f432f93265d7793bd1f2.
Separate the part which is specific for assume intrinsic from the part which only requires an icmp,
so that the latter could be reused for other purposes (e.g. in dominating conditions).
Differential Revision: https://reviews.llvm.org/D149940
Reviewed By: nikic
Appears to be causing out-of-tree test failures. Reverting while the
issue is investigated.
This reverts commit fbc7fcf5ae26fad7db3e7c861fc6447e02b39cf0.
This just replaces the exact constant requirements with known-bits
which can prove better results.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D149423
Two changes:
1) Make some cases that conditionally returned unconditional.
2) In cases of `Op0 != 0 || Op1 != 0` its better check `Op1` first
as its more likely to be a constant due to canonicalization (so
faster to get knownbits of).
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D149419
