| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
isKnownNonZero
For load instructions, computeKnownBits only checks the range metadata.
This check is already present in isKnownNonZero, so there is no need to
fall through to computeKnownBits.
This change gives a speed improvement of 0.12-0.18%:
https://llvm-compile-time-tracker.com/compare.php?from=3c6ed559e5274307995586c1499a2c8e4e0276a0&to=78b462d8c4ae079638b728c6446da5999c4ee9f8&stat=instructions:u
Differential Revision: https://reviews.llvm.org/D155958
|
|
Work around the lack of proper multiple return values by looking
at the extractvalue.
https://reviews.llvm.org/D150982
|
|
Prefer checking for non-zero operator before non-zero via
dominating conditions. This is to make sure we don't have
compile-time regressions when special cases that are currently
part of isKnownNonZero() get moved into isKnownNonZeroFromOperator().
|
|
Split off the primary part of the isKnownNonZero() implementation,
in the same way it is done for computeKnownBits(). This makes it
easier to reorder different parts of isKnownNonZero().
|
|
Fold strcmp() against 1-char string literals.
This designates AggressiveInstCombine as the pass for libcalls
simplifications that may need to change the control flow graph.
Fixes https://github.com/llvm/llvm-project/issues/58003.
Differential Revision: https://reviews.llvm.org/D154725
|
|
This mostly manifested as broken constant folding. This was
mishandling the dynamic denormal mode. It was also mishandling literal
signaling nans, such that they would also be treated as poison.
https://reviews.llvm.org/D155437
|
|
Fixes regression reported after
0f4eb557e87912afa412b1b0299d10eb7443410b
|
|
This patch is separated from D154953 to see what tests are affected by this
change alone according comment.
Depend on the related updating of LangRef on D155193.
Reviewed By: paulwalker-arm, nikic, david-arm
Differential Revision: https://reviews.llvm.org/D155350
|
|
Improve computeKnownFPClass select handling to cover the case where
the condition performs a class test. This allows us to recognize
no-nans in cases like:
%not.nan = fcmp ord float %x, 0.0
%select = select i1 %not.nan, float %x, float 0.0
Math library code has similar edge case filtering on the inputs and
final results.
https://reviews.llvm.org/D153089
|
|
This is now just a wrapper around computeKnownFPClass.
|
|
The implementations of a number of math functions on amdgpu involve
pre and post-scaling the inputs out of the denormal range. If these
are chained together we can possibly fold them out.
computeConstantRange seems weaker than computeKnownBits, so this
regresses some of the older vector tests.
|
|
https://reviews.llvm.org/D149590
|
|
Support the canonical range check pattern for KnownBits assumptions.
This is the same as the generic ConstantRange handling, just shifted
by an offset.
|
|
For non-equality icmps, we don't do any KnownBits-specific
reasoning, and just use the known bits as a constraint on the range.
We can generalize this for all predicates by round-tripping through
ConstantRange and using makeAllowedICmpRegion().
The minor improvement in zext-or-icmp is because we assume that
a value is ult [0,1], which means it must be zero.
|
|
When processing assumes, we also handle assumes on ptrtoint of the
value. In canonical IR, these will have the same size as the value.
However, in non-canonical IR there may be an implicit zext or
trunc, which results in a bit width mismatch. We currently handle
this by adjusting bitwidth everywhere, but this is fragile and I'm
pretty sure that the way we do this is incorrect for some predicates,
because we effectively end up commuting an ext/trunc and an icmp.
Instead, add an m_PtrToIntSameSize() matcher that will only handle
bitwidth preserving cases. For the bitwidth-changing cases, wait
until they have been canonicalized.
The original handling for this was added purely to prevent crashes
in an earlier implementation which failed to account for this
entirely.
|
|
dereferecable_or_null attribute
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D153945
|
|
Use a unit test since I don't see any existing uses try to make use of
the high bits of a pointer.
This will also assert if the metadata type doesn't match the pointer
width, but I consider that a defect in the verifier and shouldn't be
handled.
AMDGPU allocates LDS globals by assigning !absolute_symbol with the
final fixed address. Tracking the high bits are 0 may help with
addressing mode matching.
|
|
|
|
|
|
Move cannotBeOrderedLessThanZero logic into computeKnownFPClass.
|
|
The DataLayout alloca address space is the address space that should
be used when creating new allocas. However, not all allocas are
required to be in this address space. The isKnownNonZero() check
should work on the actual address space of the alloca, not the
default alloca address space.
|
|
This avoids a regression when SignBitMustBeZero is moved to computeKnownFPClass.
|
|
This will help enable a cleanup of simplifyFCmpInst
|
|
This reverts commit 464dcab8a6c823c9cb462bf4107797b8173de088.
Going to fix forward size regression instead due to more dependent patches needing to be reverted otherwise.
|
|
This reverts commit a632ca4b00279baf18e72a171ec0ce526e9d80aa.
Dependent commit to be reverted
|
|
This was mishandling maybe 0 * inf.
Fixes issue #63316
|
|
`V1 >> V2 u<= V1` for any V1, V2
This works for lshr and any div's that are changed to lshr's
This fixes issues in clang and rustc:
https://github.com/llvm/llvm-project/issues/62441
https://github.com/rust-lang/rust/issues/110971
Reviewed By: goldstein.w.n
Differential Revision: https://reviews.llvm.org/D151541
|
|
Define the function @llvm.amdgcn.make.buffer.rsrc, which take a 64-bit
pointer, the 16-bit stride/swizzling constant that replace the high 16
bits of an address in a buffer resource, the 32-bit extent/number of
elements, and the 32-bit flags (the latter two being the 3rd and 4th
wards of the resource), and combines them into a ptr addrspace(8).
This intrinsic is lowered during the early phases of the backend.
This intrinsic is needed so that alias analysis can correctly infer
that a certain buffer resource points to the same memory as some
global pointer. Previous methods of constructing buffer resources,
which relied on ptrtoint, would not allow for such an inference.
Depends on D148184
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D148957
|
|
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.
|
|
These implement essentially the same thing, so normalize
ValueTracking to use SimplifyQuery. In the future we can directly
expose the SimplifyQuery-based APIs.
|
|
The ORE argument threaded through ValueTracking is used only in a
single, untested place. It is also essentially never passed: The
only places that do so have been added very recently as part of the
KnownFPClass migration, which is vanishingly unlikely to hit this
code path. Remove this effectively dead argument.
Differential Revision: https://reviews.llvm.org/D151562
|
|
Make ValueTracking directly call the KnownBits shift helpers, which
provides more precise results.
Unfortunately, ValueTracking has a special case where sometimes we
determine non-zero shift amounts using isKnownNonZero(). I have my
doubts about the usefulness of that special-case (it is only tested
in a single unit test), but I've reproduced the special-case via an
extra parameter to the KnownBits methods.
Differential Revision: https://reviews.llvm.org/D151816
|
|
generating flags or metadatas when implying poison"
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.
|
|
With this, the body of CannotBeNegativeZero can be dropped.
|
|
In `select c, x, y` the condition `c` dominates the resulting `x` or
`y` chosen by the `select`. This adds logic to `isKnownNonZero` to try
and use the `icmp` for the `c` condition to see if it implies the
select `x` or `y` are known non-zero.
For example in:
```
%c = icmp ugt i8 %x, %C
%r = select i1 %c, i8 %x, i8 %y
```
The true arm of select `%x` is non-zero (when "returned" by the
`select`) because `%c` being true implies `%x` is non-zero.
Alive2 Links (with `x {pred} C`):
- EQ iff `C != 0`:
- https://alive2.llvm.org/ce/z/umLabn
- NE iff `C == 0`:
- https://alive2.llvm.org/ce/z/DQvy8Y
- UGT [always]:
- https://alive2.llvm.org/ce/z/HBkjgQ
- UGE iff `C != 0`:
- https://alive2.llvm.org/ce/z/LDNifB
- SGT iff `C s>= 0`:
- https://alive2.llvm.org/ce/z/QzWDj3
- SGE iff `C s> 0`:
- https://alive2.llvm.org/ce/z/rR4g3D
- SLT iff `C s<= 0`:
- https://alive2.llvm.org/ce/z/uysayx
- SLE iff `C s< 0`:
- https://alive2.llvm.org/ce/z/2jYc7e
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D147900
|
|
saturating add/sub functions
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
|
|
This reverts commit d1dc3e13a791fe1b99a341406b5dafec64750cb1.
200bdd9e869e2982f54923b05e54c117fd33f5d9 should have fixed
the reported regression.
|
|
CannotBeNegativeZero
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.
|
|
generating flags or metadatas when implying poison
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
|
|
This reverts commit 73925ef8b0eacc6792f0e3ea21a3e6d51f5ee8b0.
Introduces test failures, mismatch inf/nan
|
|
|
|
This reverts commit e13f88d1ff5234946af6349a9a7cf56fcb6c040e.
Fix off by one recursion limit check.
|
|
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.
|
|
This reverts commit cac9e427eb1ff3dabda8ac08968b998c3bc5ab47.
Causing crashes in lencod
|
|
Doesn't try the all the tricks computeKnownBits does.
|
|
This should now be redundant with the nan handling in computeKnownFPClass.
|
|
computeKnownFPClass should now handle infinity checks equally as
well as what this could do before so delete the redundant code.
|
