| Age | Commit message (Collapse) | Author |
|---|
|
Similarly to what it is being done to match simple recurrence cycle
relations, attempt to match value-accumulating recurrences of kind:
```
%umax.acc = phi i8 [ %umax, %backedge ], [ %a, %entry ]
%umax = call i8 @llvm.umax.i8(i8 %umax.acc, i8 %b)
```
Preliminary work to let InstCombine avoid folding such recurrences,
so that simple loop-invariant computation may get hoisted. Minor
opportunity to refactor out code as well.
|
|
b` (#145105)
Alive2: https://alive2.llvm.org/ce/z/an9npN
Fixes #142283.
|
|
(#144686)
In our downstream GPU target, following IR is valid before instcombine
although the second addrspacecast causes UB.
define i1 @test(ptr addrspace(1) noundef %v) {
%0 = addrspacecast ptr addrspace(1) %v to ptr addrspace(4)
%1 = call i32 @llvm.xxxx.isaddr.shared(ptr addrspace(4) %0)
%2 = icmp eq i32 %1, 0
%3 = addrspacecast ptr addrspace(4) %0 to ptr addrspace(3)
%4 = select i1 %2, ptr addrspace(3) null, ptr addrspace(3) %3
%5 = icmp eq ptr addrspace(3) %4, null
ret i1 %5
}
We have a custom optimization that replaces invalid addrspacecast with
poison, and IR is still valid since `select` stops poison propagation.
However, instcombine pass optimizes `select` to `or`:
%0 = addrspacecast ptr addrspace(1) %v to ptr addrspace(4)
%1 = call i32 @llvm.xxxx.isaddr.shared(ptr addrspace(4) %0)
%2 = icmp eq i32 %1, 0
%3 = addrspacecast ptr addrspace(1) %v to ptr addrspace(3)
%4 = icmp eq ptr addrspace(3) %3, null
%5 = or i1 %2, %4
ret i1 %5
The transform is invalid for our target.
---------
Co-authored-by: Nikita Popov <github@npopov.com>
|
|
Co-authored-by: Yingwei Zheng <dtcxzyw2333@gmail.com>
|
|
Reverts llvm/llvm-project#125935
Causes miscompiles, see comments in #125935
|
|
Closes #125228
|
|
Seeing how we can't generate any debug intrinsics any more: delete a
variety of codepaths where they're handled. For the most part these are
plain deletions, in others I've tweaked comments to remain coherent, or
added a type to (what was) type-generic-lambdas.
This isn't all the DbgInfoIntrinsic call sites but it's most of the
simple scenarios.
Co-authored-by: Nikita Popov <github@npopov.com>
|
|
|
|
This also patches HashRecognize to avoid it mishandling some opcodes.
|
|
We can determine the range from a subtraction if it has nsw or nuw.
https://alive2.llvm.org/ce/z/tXAKVV
|
|
Alive2: https://alive2.llvm.org/ce/z/cJ75Ya
Closes https://github.com/llvm/llvm-project/issues/117436.
|
|
When the original predicate is ordered and both operands are non-NaN,
`Ordered` should be set to true. This variable still matters even if
both operands are non-NaN because FMF only applies to select, not fcmp.
Closes https://github.com/llvm/llvm-project/issues/143123.
|
|
isGuaranteedNotToBeUndefOrPoison. (#142894)
Scalable vectors use insertelt+shufflevector ConstantExpr to
represent a splat.
|
|
computeKnownFPClass. (#143051)
We can support scalable vectors by setting the demanded mask to APInt(1,
1) to demand the whole vector.
|
|
Having a finite Depth (or recursion limit) for computeKnownBits is very
limiting, but is currently a load-bearing necessity, as all KnownBits
are recomputed on each call and there is no caching. As a prerequisite
for an effort to remove the recursion limit altogether, either using a
clever caching technique, or writing a easily-invalidable KnownBits
analysis, make the Depth argument in APIs in ValueTracking uniformly the
last argument with a default value. This would aid in removing the
argument when the time comes, as many callers that currently pass 0
explicitly are now updated to omit the argument altogether.
|
|
|
|
This patch introduces an FMF parameter for
`matchDecomposedSelectPattern` to pass FMF flags from select, instead of
fcmp.
Closes https://github.com/llvm/llvm-project/issues/137998.
Closes https://github.com/llvm/llvm-project/issues/141017.
|
|
Already handled by default case.
|
|
more cases (#141015)
This patch was originally part of
https://github.com/llvm/llvm-project/pull/139861. It generalizes
`ignoreSignBitOfZero/NaN` to handle more instructions/intrinsics.
BTW, I find it mitigates performance regressions caused by
https://github.com/llvm/llvm-project/pull/141010 (IR diff
https://github.com/dtcxzyw/llvm-opt-benchmark/pull/2365/files). We don't
need to propagate FMF from fcmp into select, since we can infer demanded
properties from the user of select.
|
|
Proof: https://alive2.llvm.org/ce/z/oqQyxC
|
|
#140254 was previously missing 2 files in the bazel build config.
|
|
This reverts commit d00d74bb2564103ae3cb5ac6b6ffecf7e1cc2238.
The PR breaks our buildbots and blocks downstream merge.
|
|
add `GenericFloatingPointPredicateUtils` in order to generalize
effects of floating point comparisons on `KnownFPClass` for both IR and
MIR.
---------
Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
|
|
The inrange constexpr GEP case is handled since 425cbbc602c9.
|
|
As requested in https://github.com/llvm/llvm-project/pull/138961#discussion_r2078483175
|
|
For now use the same treatment as minnum/maxnum, but these should
diverge. alive2 seems happy with this, except for some preexisting bugs
with weird denormal modes.
|
|
|
|
`isSafeToSpeculativelyExecute` (#137604)
Closes https://github.com/llvm/llvm-project/issues/137582.
In the original case, LVI uses the edge information in `%entry ->
%if.end` to get a more precise result. However, since the call to `smin`
has an `noundef` return attribute, an immediate UB will be triggered
after optimization.
Currently, `isSafeToSpeculativelyExecuteWithOpcode(%min)` returns true
because
https://github.com/llvm/llvm-project/commit/6a288c1e32351d4be3b7630841af078fa1c3bb8b
only checks whether the function is speculatable. However, it is not
enough in this case.
This patch takes UB-implying attributes into account if
`IgnoreUBImplyingAttrs` is set to false. If it is set to true, the
caller is responsible for correctly propagating UB-implying attributes.
|
|
Reapply after d51b2785abf77978d9218a7b6fb5b8ec6c770c31, which should
fix optimization regressions.
After #135642 we have a range attribute on the intrinsic declaration,
so we should not need the special handling here.
|
|
This does seem to cause some functionality to change, see comment on
https://github.com/llvm/llvm-project/commit/278c429d11e63bc709ea8c537b23c4e350ce2a07
This reverts commit 278c429d11e63bc709ea8c537b23c4e350ce2a07.
|
|
After #135642 we have a range attribute on the intrinsic declaration,
so we should not need the special handling here.
|
|
This patch avoids adding RHS for comparisons with two variable operands
(https://github.com/llvm/llvm-project/pull/118493#discussion_r1949397482).
Instead, we iterate over related dominating conditions of both V1 and V2
in `isKnownNonEqualFromContext`, as suggested by goldsteinn
(https://github.com/llvm/llvm-project/pull/117442#discussion_r1944058002).
Compile-time improvement:
https://llvm-compile-time-tracker.com/compare.php?from=c6d95c441a29a45782ff72d6cb82839b86fd0e4a&to=88464baedd7b1731281eaa0ce4438122b4d218a7&stat=instructions:u
|
|
proof: https://alive2.llvm.org/ce/z/zAspzb
|
|
|
|
KnownBits passed to computeKnownBitsFromRangeMetadata must have the same
bit width as the range metadata bit width. Otherwise the calculated
results will be incorrect.
---------
Signed-off-by: John Lu <John.Lu@amd.com>
|
|
- extract KnownFPClass for future use inside of GISelKnownBits
---------
Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
|
|
The test file is over 4GiB, which is too big, so I didn’t submit it.
|
|
(#130477)
In https://github.com/llvm/llvm-project/pull/97762, we assume the
minimum possible value of X is NaN implies X is NaN. But it doesn't hold
for x86_fp80 format. If the knownbits of X are
`?'011111111111110'????????????????????????????????????????????????????????????????`,
the minimum possible value of X is NaN/unnormal. However, it can be a
normal value.
Closes https://github.com/llvm/llvm-project/issues/130408.
|
|
`isGuaranteedNotToBeUndefOrPoison` (#130111)
Fixes (keep it open) #130110.
If the incoming value is PHI itself, we can skip this. If we can
guarantee that the other incoming values are neither undef nor poison,
then we can also guarantee that the value isn't either. If we cannot
guarantee that, it makes no sense in calculating it.
|
|
(#127218)
When a wider scalar/vector type containing all sign bits is bitcast to a
narrower vector type, we can deduce that the resulting narrow elements
will also be all sign bits. This matches existing behavior in
SelectionDAG and helps optimize cases involving SSE intrinsics where
sign-extended values are bitcast between different vector types.
The current implementation fails to recognize that an arithmetic right
shift is redundant when applied to elements that are already known to be
all sign bits. This PR improves ComputeNumSignBitsImpl to track this
information through bitcasts, enabling the optimization of such cases.
```
%ext = sext <1 x i1> %cmp to <1 x i8>
%sub = bitcast <1 x i8> %ext to <4 x i2>
%sra = ashr <4 x i2> %sub, <i2 1, i2 1, i2 1, i2 1>
; Can be simplified to just:
%sub = bitcast <1 x i8> %ext to <4 x i2>
```
Closes #87624
|
|
RISCVTargetParser.h. NFC (#127585)
The VLMUL and policy enums originally lived in RISCVBaseInfo.h in the
backend which is where everything else in the RISCVII namespace is
defined.
RISCVTargetParser.h is used by much more of the compiler and it
doesn't really make sense to have 2 different namespaces exposed.
These enums are both associated with VTYPE so using the RISCVVType
namespace seems like a good home for them.
|
|
commit 0517772b4ac20c5d3a0de0d4703354a179833248
Author: Philip Reames <preames@rivosinc.com>
Date: Thu Dec 19 14:14:11 2024 -0800
|
|
The last use was removed in:
commit ac9e67756e0157793d565c2cceaf82e4403f58ba
Author: Yingwei Zheng <dtcxzyw2333@gmail.com>
Date: Mon Feb 26 01:53:16 2024 +0800
|
|
This patch adds context-sensitive analysis support for
`isKnownNonEqual`. It is required for
https://github.com/llvm/llvm-project/issues/117436.
|
|
(#126414)
proof: https://alive2.llvm.org/ce/z/gALGmv
|
|
General handling of not in dominating condition.
proof: https://alive2.llvm.org/ce/z/FjJN8q
|
|
|
|
|
|
`computeKnownBitsFromCmp`. NFCI. (#125666)
I believe it is unused since we always convert it into `V == Mask ^ C`.
Code coverage:
https://dtcxzyw.github.io/llvm-opt-benchmark/coverage/data/zyw/opt-ci/actions-runner/_work/llvm-opt-benchmark/llvm-opt-benchmark/llvm/llvm-project/llvm/lib/Analysis/ValueTracking.cpp.html#L706
|
|
For GEPs, we have three bit widths involved: The pointer bit width, the
index bit width, and the bit width of the GEP operands.
The correct behavior here is:
* We need to sextOrTrunc the GEP operand to the index width *before*
multiplying by the scale.
* If the index width and pointer width differ, GEP only ever modifies
the low bits. Adds should not overflow into the high bits.
I'm testing this via unit tests because it's a bit tricky to test in IR
with InstCombine canonicalization getting in the way.
|
