[LLVM][IR] Use splat syntax when printing ConstantExpr based splats. (#116856)

This brings the printing of scalable vector constant splats inline with
their fixed length counterparts.

[LLVM][IR] Use splat syntax when printing Constant[Data]Vector. (#112548)

[LLVM][tests/Transforms/InstCombine] Convert instances of ConstantExpr based splats to use splat().

This is mostly NFC but some output does change due to consistently
inserting into poison rather th

[LLVM][tests/Transforms/InstCombine] Convert instances of ConstantExpr based splats to use splat().

This is mostly NFC but some output does change due to consistently
inserting into poison rather than undef and using i64 as the index
type for inserts.

show more ...

[InstCombine] Canonicalize constant GEPs to i8 source element type (#68882)

This patch canonicalizes getelementptr instructions with constant
indices to use the `i8` source element type. This makes

[InstCombine] Canonicalize constant GEPs to i8 source element type (#68882)

This patch canonicalizes getelementptr instructions with constant
indices to use the `i8` source element type. This makes it easier for
optimizations to recognize that two GEPs are identical, because they
don't need to see past many different ways to express the same offset.

This is a first step towards
https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699.
This is limited to constant GEPs only for now, as they have a clear
canonical form, while we're not yet sure how exactly to deal with
variable indices.

The test llvm/test/Transforms/PhaseOrdering/switch_with_geps.ll gives
two representative examples of the kind of optimization improvement we
expect from this change. In the first test SimplifyCFG can now realize
that all switch branches are actually the same. In the second test it
can convert it into simple arithmetic. These are representative of
common optimization failures we see in Rust.

Fixes https://github.com/llvm/llvm-project/issues/69841.

show more ...

[InstCombine] Handle load smaller than one byte in memset forward

APInt::getSplat() requires that the new size is >= the original
one. If we're loading less than 8 bits, truncate instead.

Fixes htt

[InstCombine] Handle load smaller than one byte in memset forward

APInt::getSplat() requires that the new size is >= the original
one. If we're loading less than 8 bits, truncate instead.

Fixes https://github.com/llvm/llvm-project/issues/58845.

show more ...

[InstCombine] Perform memset -> load forwarding

InstCombine does some basic store to load forwarding. One case it
currently misses is the case where the store is actually a memset.
This patch adds s

[InstCombine] Perform memset -> load forwarding

InstCombine does some basic store to load forwarding. One case it
currently misses is the case where the store is actually a memset.
This patch adds support for this case. This is a minimal
implementation that only handles a load at the memset base address,
without an offset.

GVN is already capable of performing this optimization. Having it
in InstCombine can help with phase ordering issues, similar to the
existing store to load forwarding.

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

show more ...

[InstCombine] Add more memset->load forwarding tests (NFC)

[InstCombine] Add tests for memset -> load forward with offset (NFC)

[InstCombine] Add tests for memset -> load forwarding (NFC)

We currently only forward store -> load, but could do the same
for memset as well.

[test][InstCombine] Update some test cases to use opaque pointers

These tests cases were converted using the script at
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34

Differential Re

[test][InstCombine] Update some test cases to use opaque pointers

These tests cases were converted using the script at
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34

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

show more ...

[Loads] Check type size in bits during store to load forwarding

Rather than checking the rounded type store size, check the type
size in bits. We don't want to forward a store of i1 to a load
of i8

[Loads] Check type size in bits during store to load forwarding

Rather than checking the rounded type store size, check the type
size in bits. We don't want to forward a store of i1 to a load
of i8 for example, even though they have the same type store size.
The padding bits have unspecified contents.

This is a partial fix for the issue reported at
https://reviews.llvm.org/D115924#inline-1179482,
the problem also needs to be addressed more generally in the
constant folding code.

show more ...

[ConstantFold] Add test for load of i8 from i1 (NFC)

Semantics here are a bit unclear, but the store-to-load forwarding
case at least should be a miscompile.

[InstCombine] Bail out of load-store forwarding for scalable vector types

This patch fixes an invalid TypeSize->uint64_t implicit conversion in
FoldReinterpretLoadFromConst. If the size of the const

[InstCombine] Bail out of load-store forwarding for scalable vector types

This patch fixes an invalid TypeSize->uint64_t implicit conversion in
FoldReinterpretLoadFromConst. If the size of the constant is scalable
we bail out of the optimisation for now.

Tests added here:

Transforms/InstCombine/load-store-forward.ll

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

show more ...

[test] Use -passes=instcombine instead of -instcombine in lots of tests. NFC

Another step moving away from the deprecated syntax of specifying
pass pipeline in opt.

Differential Revision: https://r

[test] Use -passes=instcombine instead of -instcombine in lots of tests. NFC

Another step moving away from the deprecated syntax of specifying
pass pipeline in opt.

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

show more ...

[ConstantFold] Don't fold load from non-byte-sized vector

Following up on https://github.com/llvm/llvm-project/commit/1470f94d71c544327f76b85c55cb6f7cb43a6cbb#r63981173:

The result here (probably)

[ConstantFold] Don't fold load from non-byte-sized vector

Following up on https://github.com/llvm/llvm-project/commit/1470f94d71c544327f76b85c55cb6f7cb43a6cbb#r63981173:

The result here (probably) depends on endianness. Don't bother
trying to handle this exotic case, just bail out.

show more ...

[Loads] Use more powerful constant folding API

This follows up on D111023 by exporting the generic "load value
from constant at given offset as given type" and using it in the
store to load forwardi

[Loads] Use more powerful constant folding API

This follows up on D111023 by exporting the generic "load value
from constant at given offset as given type" and using it in the
store to load forwarding code. We now need to make sure that the
load size is smaller than the store size, previously this was
implicitly ensured by ConstantFoldLoadThroughBitcast().

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

show more ...

[InstCombine] Add additional store forwarding test (NFC)

Variant where the load is larger than the store. Make sure we
don't forward this.

[InstCombine] Add load/store forwarding test with odd size (NFC)

Test the case where the type size doesn't equal the store size,
as suggested by bjope.

[Loads] Forward constant vector store to load of first element

InstCombine performs simple forwarding from stores to loads, but
currently only handles the case where the load and store have the
same

[Loads] Forward constant vector store to load of first element

InstCombine performs simple forwarding from stores to loads, but
currently only handles the case where the load and store have the
same size. This extends it to also handle a store of a constant
with a larger size followed by a load with a smaller size.

This is implemented through ConstantFoldLoadThroughBitcast() which
is fairly primitive (e.g. does not allow storing a large integer
and then loading a small one), but at least can forward the first
element of a vector store. Unfortunately it seems that we currently
don't have a generic helper for "read a constant value as a different
type", it's all tangled up with other logic in either
ConstantFolding or VNCoercion.

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

show more ...

[InstCombine] Add tests for non-trivial store to load forward (NFC)

Examples of things we mostly don't handle.