[InstCombine] Make use of low zero bits to determine exact int->fp cast

According the comment https://reviews.llvm.org/D127854#inline-1226805,
We could also make use of these low zero bits, https://

[InstCombine] Make use of low zero bits to determine exact int->fp cast

According the comment https://reviews.llvm.org/D127854#inline-1226805,
We could also make use of these low zero bits, https://alive2.llvm.org/ce/z/GYxTRu

Reviewed By: spatel, nikic, xbolva00

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

show more ...

[InstCombine] Use known bits to determine exact int->fp cast

Reviewed By: spatel, nikic

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

[llvm] Don't use Optional::getValue (NFC)

[InstCombine] decomposeSimpleLinearExpr should bail out on negative operands.

InstCombine tries to rewrite

%prod = mul nsw i64 %X, Scale
%acc = add nsw i64 %prod, Offset
%0 = alloca i8, i

[InstCombine] decomposeSimpleLinearExpr should bail out on negative operands.

InstCombine tries to rewrite

%prod = mul nsw i64 %X, Scale
%acc = add nsw i64 %prod, Offset
%0 = alloca i8, i64 %acc, align 4
%1 = bitcast i8* %0 to i32*
Use ( %1 )

into

%prod = mul nsw i64 %X, Scale/4
%acc = add nsw i64 %prod, Offset/4
%0 = alloca i32, i64 %acc, align 4
Use (%0)

But it assumes Scale is unsigned, and performs an unsigned division.
So we should bail out if Scale cannot be interpreted as an unsigned safely.

Reviewed By: nikic

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

show more ...

[InstCombine] bitcast (extractelement <1 x elt>, dest) -> bitcast(<1 x elt>, dest)

Only solve dest type is vector to avoid inverse transform in visitBitCast.

Reviewed By: spatel

Differential Revis

[InstCombine] bitcast (extractelement <1 x elt>, dest) -> bitcast(<1 x elt>, dest)

Only solve dest type is vector to avoid inverse transform in visitBitCast.

Reviewed By: spatel

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

show more ...

[InstCombine] bitcast(logic(bitcast(X), bitcast(Y))) -> bitcast'(logic(bitcast'(X), Y))

This patch break foldBitCastBitwiseLogic limite the destination
must have an integer element type, and elimina

[InstCombine] bitcast(logic(bitcast(X), bitcast(Y))) -> bitcast'(logic(bitcast'(X), Y))

This patch break foldBitCastBitwiseLogic limite the destination
must have an integer element type, and eliminate one bitcast by
doing the logic op in the type of the input that has an integer
element type.

Reviewed By: spatel

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

show more ...

[InstCombine] [NFC] Move transforms for truncated shifts into narrowBinOp

Reviewed By: spatel

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

[InstCombine] [NFC] Use a pattern matcher for ExtractElementInst

Reviewed By: RKSimon, rampitec

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

[InstCombine] remove cast-of-signbit to shift transform

The transform was wrong in 3 ways:

1. It created an extra instruction when the source and dest types don't match.
2. It did not account for a

[InstCombine] remove cast-of-signbit to shift transform

The transform was wrong in 3 ways:

1. It created an extra instruction when the source and dest types don't match.
2. It did not account for an extra use of the icmp, so could create 2 extra insts.
3. It favored bit hacks over icmp (icmp generally has better analysis).

This fixes #54692 (modeled by the PhaseOrdering tests).

This is a minimal step to fix the bug, but we should likely invert
this and the sibling transform for the "is negative" pattern too.

The backend should be able to invert this back to a shift if that
leads to better codegen.

This is a reduced try of 3794cc0e9964 - that was reverted because
it could cause infinite loops by conflicting with the related
transforms in this block that create shifts.

show more ...

[KnownBits] Add operator==

Checking whether two KnownBits are the same is somewhat common,
mainly in test code.

I don't think there is a lot of room for confusion with "determine
what the KnownBits

[KnownBits] Add operator==

Checking whether two KnownBits are the same is somewhat common,
mainly in test code.

I don't think there is a lot of room for confusion with "determine
what the KnownBits for an icmp eq would be", as that has a
different result type (this is what the eq() method implements,
which returns Optional<bool>).

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

show more ...

Revert "[InstCombine] invert canonicalization for cast of signbit test"

This reverts commit 3794cc0e996481e10307b67c8436aa44e0d65d22.
This change is suspected of causing bots to hang at stage 2
comp

Revert "[InstCombine] invert canonicalization for cast of signbit test"

This reverts commit 3794cc0e996481e10307b67c8436aa44e0d65d22.
This change is suspected of causing bots to hang at stage 2
compiles, so reverting to confirm and investigate.

show more ...

[InstCombine] invert canonicalization for cast of signbit test

The existing transform was wrong in 3 ways:
1. It created an extra instruction when the source and dest types don't match.
2. It did no

[InstCombine] invert canonicalization for cast of signbit test

The existing transform was wrong in 3 ways:
1. It created an extra instruction when the source and dest types don't match.
2. It did not account for an extra use of the icmp, so could create 2 extra insts.
3. It favored bit hacks over icmp (icmp generally has better analysis).

This fixes #54692 (modeled by the PhaseOrdering tests).

This is a minimal step to fix the bug, but we should likely invert
the sibling transform for the "is negative" pattern too.

The backend should be able to invert this back to a shift if that
leads to better codegen.

show more ...

[InstCombine] fix miscompile when casting int->FP->int

As shown in https://github.com/llvm/llvm-project/issues/55150 -
the existing fold may be wrong when converting to a signed value.
This is a qui

[InstCombine] fix miscompile when casting int->FP->int

As shown in https://github.com/llvm/llvm-project/issues/55150 -
the existing fold may be wrong when converting to a signed value.
This is a quick fix to avoid the miscompile.

I added tests/comments for all of the signed/unsigned combinations
at either side of the boundary width, and tried to confirm with Alive2:
https://alive2.llvm.org/ce/z/3p9DSu

There are already some TODO items in the test file that suggest
possible refinements, so the regression with ui->FP->si is probably ok.
It seems unlikely that we'd see these kind of edge cases with
non-byte-width integer types in real code. The potential miscompile
went undetected for several years.

This and 747c6a0c734e fixes #55150.

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

show more ...

[InstCombine] add casts from splat-a-bit pattern if necessary

Splatting a bit of constant-index across a value:
sext (ashr (trunc iN X to iM), M-1) to iN --> ashr (shl X, N-M), N-1
If the dest type

[InstCombine] add casts from splat-a-bit pattern if necessary

Splatting a bit of constant-index across a value:
sext (ashr (trunc iN X to iM), M-1) to iN --> ashr (shl X, N-M), N-1
If the dest type is different, use a cast (adjust use check).

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

Reviewed By: spatel

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

show more ...

[InstCombine] use isKnownNonNegative to reduce code duplication; NFC

We may be able to make the ValueTracking wrapper smarter
in the future (for example, analyze a simple recurrence),
so this will a

[InstCombine] use isKnownNonNegative to reduce code duplication; NFC

We may be able to make the ValueTracking wrapper smarter
in the future (for example, analyze a simple recurrence),
so this will automatically benefit if that happens.

show more ...

[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 ...