[InstCombine] Don't look through bitcast from vector in collectInsertionElements.

We're making a recursive call here and everything in the function
assumes we're looking at scalars. This would be vi

[InstCombine] Don't look through bitcast from vector in collectInsertionElements.

We're making a recursive call here and everything in the function
assumes we're looking at scalars. This would be violated if we
looked through a bitcast from vectors.

Reviewed By: spatel

Differential Revision: https://reviews.llvm.org/D124015

show more ...

Cleanup includes: Transform/Scalar

Estimated impact on preprocessor output line:
before: 1062981579
after: 1062494547

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cl

Cleanup includes: Transform/Scalar

Estimated impact on preprocessor output line:
before: 1062981579
after: 1062494547

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D120817

show more ...

Tweak some uses of std::iota to skip initializing the underlying storage. NFCI.

[InstCombine] Skip PromoteCastOfAllocation() transform under opaque pointers

I think this can't be hit anyway (because a ptr-to-ptr bitcast would
get folded earlier), but in the interest of being ex

[InstCombine] Skip PromoteCastOfAllocation() transform under opaque pointers

I think this can't be hit anyway (because a ptr-to-ptr bitcast would
get folded earlier), but in the interest of being explicit skip
this transform for opaque pointers entirely.

show more ...

[NFC] Remove uses of PointerType::getElementType()

Instead use either Type::getPointerElementType() or
Type::getNonOpaquePointerElementType().

This is part of D117885, in preparation for deprecatin

[NFC] Remove uses of PointerType::getElementType()

Instead use either Type::getPointerElementType() or
Type::getNonOpaquePointerElementType().

This is part of D117885, in preparation for deprecating the API.

show more ...

InstCombine: Gracefully handle more allocas in the wrong address space

Officially this is currently required to always use the datalayout's
alloca address space. This may change in the future, and i

InstCombine: Gracefully handle more allocas in the wrong address space

Officially this is currently required to always use the datalayout's
alloca address space. This may change in the future, and it's cleaner
to propagate the existing alloca's addrspace anyway.

This is a triple fix. Initially the change in simplifyAllocaArraySize
would drop the address space, but produce output. Fixing this hit an
assertion in the cast combine.

This patch also makes the changes to handle this situation from
a33e12801279a947c74fdee2655b24480941fb39 dead, so eliminate
it. InstCombine should not take it upon itself to introduce
addrspacecasts, and preserve the original address space instead.

show more ...

[IR] Split vscale_range interface

Interface is split from:

std::pair<unsigned, unsigned> getVScaleRangeArgs()

into separate functions for min/max:

unsigned getVScaleRangeMin();
Optional<uns

[IR] Split vscale_range interface

Interface is split from:

std::pair<unsigned, unsigned> getVScaleRangeArgs()

into separate functions for min/max:

unsigned getVScaleRangeMin();
Optional<unsigned> getVScaleRangeMax();

Reviewed By: sdesmalen, paulwalker-arm

Differential Revision: https://reviews.llvm.org/D114075

show more ...

[InstCombine] Allow fake vector insert folding to bit-logic only if the insert element is integer type

The below commit is causing assertion when insert element type is not integer
type such as hal

[InstCombine] Allow fake vector insert folding to bit-logic only if the insert element is integer type

The below commit is causing assertion when insert element type is not integer
type such as half. This is because the transformation is creating zext before
doing bitwise OR, and the zext is supported only for integer types
https://github.com/llvm/llvm-project/commit/80ab06c599a0f5a90951c36a57b2a9b492b19d61

Reviewed By: spatel

Differential Revision: https://reviews.llvm.org/D114734

show more ...

[Transforms] Use {DenseSet,SetVector,SmallPtrSet}::contains (NFC)

[InstCombine] fold fake vector insert to bit-logic

bitcast (inselt (bitcast X), Y, 0) --> or (and X, MaskC), (zext Y)

https://alive2.llvm.org/ce/z/Ux-662

Similar to D111082 / db231ebdb07f :
We wan

[InstCombine] fold fake vector insert to bit-logic

bitcast (inselt (bitcast X), Y, 0) --> or (and X, MaskC), (zext Y)

https://alive2.llvm.org/ce/z/Ux-662

Similar to D111082 / db231ebdb07f :
We want to avoid relatively opaque vector ops on types that are
likely supported by the backend as scalar integers. The bitwise
logic ops are more likely to allow further combining.

We probably want to generalize this to allow a shift too, but
that would oppose instcombine's general rule of not creating
extra instructions, so that's left as a potential follow-up.
Alternatively, we could do that transform in VectorCombine
with the help of the TTI cost model.

This is part of solving:
https://llvm.org/PR52057

show more ...

[APInt] Stop using soft-deprecated constructors and methods in llvm. NFC.

Stop using APInt constructors and methods that were soft-deprecated in
D109483. This fixes all the uses I found in llvm, exc

[APInt] Stop using soft-deprecated constructors and methods in llvm. NFC.

Stop using APInt constructors and methods that were soft-deprecated in
D109483. This fixes all the uses I found in llvm, except for the APInt
unit tests which should still test the deprecated methods.

Differential Revision: https://reviews.llvm.org/D110807

show more ...

[InstCombine] Fold ptrtoint(gep i8 null, x) -> x

This commit is the InstCombine follow-up to the previous constant-folding
change that enables noticeable optimizations for CHERI-enabled targets.

Re

[InstCombine] Fold ptrtoint(gep i8 null, x) -> x

This commit is the InstCombine follow-up to the previous constant-folding
change that enables noticeable optimizations for CHERI-enabled targets.

Reviewed By: nikic

Differential Revision: https://reviews.llvm.org/D110247

show more ...

[Analysis] Fix issues when querying vscale attributes on functions

There are several places in the code that are currently broken as
they assume an Instruction always has a parent Function when
atte

[Analysis] Fix issues when querying vscale attributes on functions

There are several places in the code that are currently broken as
they assume an Instruction always has a parent Function when
attempting to get the vscale_range attribute. This patch adds checks
that an Instruction has a parent.

I've added a test for a parentless @llvm.vscale intrinsic call here:

unittests/Analysis/ValueTrackingTest.cpp

Differential Revision: https://reviews.llvm.org/D110158

show more ...

[InstCombine] Update InstCombine to use poison instead of undef for shufflevector's placeholder (1/3)

This patch is for fixing potential shufflevector-related bugs like D93818.
As D93818, this patch

[InstCombine] Update InstCombine to use poison instead of undef for shufflevector's placeholder (1/3)

This patch is for fixing potential shufflevector-related bugs like D93818.
As D93818, this patch change shufflevector's default placeholder to poison.
To reduce risk, it was divided into several patches, and this patch is for InstCombineCasts.

Reviewed By: spatel

Differential Revision: https://reviews.llvm.org/D110226

show more ...

[InstCombine] remove casts from splat-a-bit pattern

https://alive2.llvm.org/ce/z/_AivbM

This case seems clear since we can reduce instruction count
and avoid an intermediate type change, but we mig

[InstCombine] remove casts from splat-a-bit pattern

https://alive2.llvm.org/ce/z/_AivbM

This case seems clear since we can reduce instruction count
and avoid an intermediate type change, but we might want to
use mask-and-compare for other sequences.

Currently, we can generate more instructions on some related
patterns by trying to use bit-hacks instead of mask+cmp, so
something is not behaving as expected.

show more ...

[InstCombine] remove a buggy set of zext-icmp transforms

The motivating case is an infinite loop shown with a reduced test from:
https://llvm.org/PR51762

To solve this, I'm proposing we delete the

[InstCombine] remove a buggy set of zext-icmp transforms

The motivating case is an infinite loop shown with a reduced test from:
https://llvm.org/PR51762

To solve this, I'm proposing we delete the most obviously broken part of this code.

The bug example shows a fundamental problem: we ask computeKnownBits if a transform
will be profitable, alter the code by creating new instructions, then rely on
computeKnownBits to return the same answer to actually eliminate instructions.

But there's no guarantee that the results will be the same between the 1st and 2nd
calls. In the infinite loop example, we get different answers, so we add
instructions that conflict with some other transform, and we're stuck.

There's at least one other problem visible in the test diff for
`@zext_or_masked_bit_test_uses`: the code doesn't check uses properly, so we can
end up with extra instructions created.

Last, it's not clear if this set of transforms actually improves analysis or
codegen. I spot-checked a few targets and don't see a clear win:
https://godbolt.org/z/x87EWovso

If we do see a regression from this change, codegen seems like the right place to
add a cmp -> bit-hack fold.

If this is too big of a step, we could limit the computeKnownBits calls by not
passing a context instruction and/or limiting the recursion. I checked that those
would stop the infinite loop for PR51762, but that won't guarantee that some other
example does not fall into the same loop.

Differential Revision: https://reviews.llvm.org/D109440

show more ...

[SVE] Add folds for truncation of vscale

Reviewed By: david-arm

Differential Revision: https://reviews.llvm.org/D107453

[InstCombine] Fix vscale zext/sext optimization when vscale_range is unbounded.

According to the LangRef, a (vscale_range) value of 0 means unbounded.

This patch additionally cleans up the test fil

[InstCombine] Fix vscale zext/sext optimization when vscale_range is unbounded.

According to the LangRef, a (vscale_range) value of 0 means unbounded.

This patch additionally cleans up the test file vscale_sext_and_zext.ll.

show more ...

[SVE] Add folds for sign and zero extends of vscale

Reviewed By: efriedma

Differential Revision: https://reviews.llvm.org/D105994

[InstCombine] Eliminate casts to optimize ctlz operation

If a ctlz operation is performed on higher datatype and then
downcasted, then this can be optimized by doing a ctlz operation
on a lower data

[InstCombine] Eliminate casts to optimize ctlz operation

If a ctlz operation is performed on higher datatype and then
downcasted, then this can be optimized by doing a ctlz operation
on a lower datatype and adding the difference bitsize to the result
of ctlz to provide the same output:

https://alive2.llvm.org/ce/z/8uup9M

The original problem is shown in
https://llvm.org/PR50173

Differential Revision: https://reviews.llvm.org/D103788

show more ...

[OpaquePtr] Handle addrspacecasts in InstCombine

This adds support for addrspace casts involving opaque pointers to
InstCombine, as well as the isEliminableCastPair() helper
(otherwise the assertion

[OpaquePtr] Handle addrspacecasts in InstCombine

This adds support for addrspace casts involving opaque pointers to
InstCombine, as well as the isEliminableCastPair() helper
(otherwise the assertion failure would just move there).

Add PointerType::hasSameElementTypeAs() to hide the element type
details.

Differential Revision: https://reviews.llvm.org/D104668

show more ...

Reapply [InstCombine] Don't try converting opaque pointer bitcast to GEP

Reapplied without changes -- this was reverted together with an
underlying patch.

-----

Bitcasts having opaque pointer sour

Reapply [InstCombine] Don't try converting opaque pointer bitcast to GEP

Reapplied without changes -- this was reverted together with an
underlying patch.

-----

Bitcasts having opaque pointer source or result type cannot be
converted into a zero-index GEP, GEP source and result types
always have the same opaque-ness.

show more ...

Reapply [InstCombine] Extract bitcast -> gep transform

Relative to the original patch, an InstCombine test has been
added to show a previously missed pattern, and the Coroutine
test that resulted in

Reapply [InstCombine] Extract bitcast -> gep transform

Relative to the original patch, an InstCombine test has been
added to show a previously missed pattern, and the Coroutine
test that resulted in the revert has been regenerated.

-----

Move this into a separate function, to make sure that early
returns do not accidentally skip other transforms. This previously
happened for the isSized() check, which skipped folds like
distributing a bitcast over a select.

show more ...

Revert "[InstCombine] Extract bitcast -> gep transform"

This reverts commit d9f5d7b959de36085944d4a99a73f3053f953796.
This reverts commit 5780611d7e044ef56c4214df2c236ef5e15545ab.

This causes a fai

Revert "[InstCombine] Extract bitcast -> gep transform"

This reverts commit d9f5d7b959de36085944d4a99a73f3053f953796.
This reverts commit 5780611d7e044ef56c4214df2c236ef5e15545ab.

This causes a failure in Coroutine tests.

show more ...

[InstCombine] Don't try converting opaque pointer bitcast to GEP

Bitcasts having opaque pointer source or result type cannot be
converted into a zero-index GEP, GEP source and result types
always ha

[InstCombine] Don't try converting opaque pointer bitcast to GEP

Bitcasts having opaque pointer source or result type cannot be
converted into a zero-index GEP, GEP source and result types
always have the same opaque-ness.

show more ...