This is a cleanup/modernization patch requested in D144045 to make loop
analysis a proper optional parameter to the pass rather than a
semi-arbitrary value inherited via the pass pipeline.
It's a bit more complicated than the recent patch I started copying from
(D143980) because InstCombine already has an option for MaxIterations
(added with D71145).
I debated just deleting that option, but it was used by a pair of existing
tests, so I put it into a struct (code largely copied from SimplifyCFG's
implementation) to make the code more flexible for future options
enhancements.
I didn't alter the pass manager invocations of InstCombine in this patch
because the patch was already getting big, but that will be a small
follow-up as noted with the TODO comment.
Differential Revision: https://reviews.llvm.org/D144199
InstCombine is supposed to be a superset of InstSimplify, but we
were not attempting simplification of insertvalue instructions.
As the test change illustrates, we failed to remove some aggregate
construction patterns because of that.
If we have both an nsw and nuw flag, we would see the nsw flag
first and only handle signed comparisons.
This patch ignores the nsw flag if the comparison isn't signed.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D143766
Similar to 62a0a1b9eea7788c1f9dbae -
We have pow math intrinsics in IR, but no ldexp intrinsics
to handle vector types.
A patch for that was proposed in D14327, but it was not completed.
Issue #60605
We have exp2 math intrinsics in IR, but no ldexp intrinsics
to handle vector types.
A patch for that was proposed in D14327, but it was not completed.
Issue #60605
The output of intrinsic functions like ctpop, cttz, ctlz have limited range from 0 to bitwidth. So if the truncate destination type can hold the source bitwidth size, we can just ignore the truncate and use the truncate src to do combination.
Alive2 proofs:
https://alive2.llvm.org/ce/z/9D_-qP
Reviewed By: spatel
Differential Revision: https://reviews.llvm.org/D143368
(V == 0) ? 1 : V --> umax(V, 1)
(V == UMAX) ? UMAX-1 : V --> umin(V, UMAX-1)
https://alive2.llvm.org/ce/z/pfDBAf
This is one pair of the variants discussed in issue #60374.
Enhancements for the other end of the constant range and
signed variants are potential follow-ups, but that may
require more work because we canonicalize at least one
min/max like that to icmp+zext.
Various parts of the codebase are using getIntPtrType() and its
relatives when getting the type of the offset argument to GEP. Most
such code has been updated to use the pointer index type field from
the data layout, but there is code that still assumes these two types
are the same in certain optimizaiton passes.
This commit adds regression tests to capture the old behavior.
Reviewed By: #amdgpu, arsenm
Differential Revision: https://reviews.llvm.org/D143435
is.fpclass(x, qnan|snan) -> fcmp uno x, 0.0
is.fpclass(nnan x, qnan|snan|other) -> is.fpclass(x, other)
Start porting the existing combines from llvm.amdgcn.class to the
generic intrinsic. Start with the ones which aren't dependent on the
FP mode.
Delete the opt intrinsics since they are now identical.
I left the side effects due to user expectations about how these
interact with things like inline assembly or function calls. Or
that they wouldn't be hoisted. I think we should look at other
ways to address thoughs.
If I could, I'd rename them these somehow to distance them from
the vsetvli instruction. In some sense they only query the VL for
a particular SEW and LMUL. They don't guarantee a vsetvli
instruction will be emitted.
Fixes https://github.com/llvm/llvm-project/issues/59359
Reviewed By: rogfer01, kito-cheng
Differential Revision: https://reviews.llvm.org/D143220
shuffle (fabs X), Mask --> fabs (shuffle X, Mask)
shuffle (fabs X), (fabs Y), Mask --> fabs (shuf X, Y, Mask)
https://alive2.llvm.org/ce/z/JH2nkf
This generalizes the existing fneg transforms to also work with fabs.
A likely follow-up would generalize this further to move any unary
intrinsic op.
The LoopVectorizer emits the (scaled) element count as i32, which for
scalable VFs results in calls to @llvm.vscale.i32(). This value is scaled
and further zero-extended to i64.
The zero-extend can be folded away by executing the whole expression in i64
type using @llvm.vscale.i64(). Any logical `and` that would needed to mask
the result can be further folded away by KnownBits analysis when
vscale_range is set.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D143016
