[GVN] Handle scalable vectors with the same size in VNCoercion (#123984)

This allows us to forward to a load even if the types do not match
(nxv4i32 vs nxv2i64 for example). Scalable types are allo

[GVN] Handle scalable vectors with the same size in VNCoercion (#123984)

This allows us to forward to a load even if the types do not match
(nxv4i32 vs nxv2i64 for example). Scalable types are allowed in
canCoerceMustAliasedValueToLoad so long as the size (minelts *
scalarsize) is the same, and some follow-on code is adjusted to make
sure it handles scalable sizes correctly. Methods like
analyzeLoadFromClobberingWrite and analyzeLoadFromClobberingStore still
do nothing for scalable vectors, as Offsets and mismatching types are
not supported.

show more ...

[Utils] Remove unused includes (NFC) (#114748)

Identified with misc-include-cleaner.

[VNCoercion] Drop some redundant functions (NFC)

These load and store APIs now do the same thing, so combine them
into one.

[GVN][VNCoercion] Remove load widening leftovers (NFCI)

GVN load widening was disabled in D24096. This removes various
support code that is no longer relevant.

The way this works nowadays is that w

[GVN][VNCoercion] Remove load widening leftovers (NFCI)

GVN load widening was disabled in D24096. This removes various
support code that is no longer relevant.

The way this works nowadays is that we return PartialAlias with
an offset from BasicAA and this gets passed on as a clobber by
MDA. However, PartialAlias will only be returned if the load is
properly nested inside the other load.

This just removes the bulk of the code, but some additional
cleanup can be done here now that we don't need to distinguish
between load and store cases.

show more ...

Use llvm::bit_ceil (NFC)

Note that:

std::has_single_bit(X) ? X : llvm::NextPowerOf2(X);

is equivalent to:

std::bit_ceil(X)

even for input 0.

[NFC] Use TypeSize::geFixedValue() instead of TypeSize::getFixedSize()

This change is one of a series to implement the discussion from
https://reviews.llvm.org/D141134.

[IR] Add a target extension type to LLVM.

Target-extension types represent types that need to be preserved through
optimization, but otherwise are not introspectable by target-independent
optimizati

[IR] Add a target extension type to LLVM.

Target-extension types represent types that need to be preserved through
optimization, but otherwise are not introspectable by target-independent
optimizations. This patch doesn't add any uses of these types by an existing
backend, it only provides basic infrastructure such that these types would work
correctly.

Reviewed By: nikic, barannikov88

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

show more ...

Take memset_inline into account in analyzeLoadFromClobberingMemInst

This appeared in https://reviews.llvm.org/D126903#3884061

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

[VNCoercion] Separate constant/non-constant mem intrinsic implementations (NFCI)

This means we no longer need to have the same API between IRBuilder
and IRBuilderFolder.

The constant case is substa

[VNCoercion] Separate constant/non-constant mem intrinsic implementations (NFCI)

This means we no longer need to have the same API between IRBuilder
and IRBuilderFolder.

The constant case is substantially simpler, so implementing it
separately isn't an undue burden.

show more ...

[VNCoercion] Use ConstantFoldLoadFromConst API (NFCI)

Nowdays we have a generic constant folding API to load a type from
an offset. It should be able to do anything that VNCoercion can do.

This avo

[VNCoercion] Use ConstantFoldLoadFromConst API (NFCI)

Nowdays we have a generic constant folding API to load a type from
an offset. It should be able to do anything that VNCoercion can do.

This avoids the weird templating between IRBuilder and ConstantFolder
in one function, which is will stop working as the IRBuilderFolder
moves from CreateXYZ to FoldXYZ APIs.

Unfortunately, this doesn't eliminate this pattern from VNCoercion
entirely yet.

show more ...

[NFC][Alignment] Use getAlign in VNCoercion

Cleanup header dependencies in LLVMCore

Based on the output of include-what-you-use.

This is a big chunk of changes. It is very likely to break downstream code
unless they took a lot of care in avo

Cleanup header dependencies in LLVMCore

Based on the output of include-what-you-use.

This is a big chunk of changes. It is very likely to break downstream code
unless they took a lot of care in avoiding hidden ehader dependencies, something
the LLVM codebase doesn't do that well :-/

I've tried to summarize the biggest change below:

- llvm/include/llvm-c/Core.h: no longer includes llvm-c/ErrorHandling.h
- llvm/IR/DIBuilder.h no longer includes llvm/IR/DebugInfo.h
- llvm/IR/IRBuilder.h no longer includes llvm/IR/IntrinsicInst.h
- llvm/IR/LLVMRemarkStreamer.h no longer includes llvm/Support/ToolOutputFile.h
- llvm/IR/LegacyPassManager.h no longer include llvm/Pass.h
- llvm/IR/Type.h no longer includes llvm/ADT/SmallPtrSet.h
- llvm/IR/PassManager.h no longer includes llvm/Pass.h nor llvm/Support/Debug.h

And the usual count of preprocessed lines:
$ clang++ -E -Iinclude -I../llvm/include ../llvm/lib/IR/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
before: 6400831
after: 6189948

200k lines less to process is no that bad ;-)

Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup

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

show more ...

[GVN][NFC] Remove redundant check

The if-check above deleted part guarantees that StoreOffset <= LoadOffset
and that StoreOffset + StoreSize >= LoadOffset + LoadSize, and given that
LoadOffset + Loa

[GVN][NFC] Remove redundant check

The if-check above deleted part guarantees that StoreOffset <= LoadOffset
and that StoreOffset + StoreSize >= LoadOffset + LoadSize, and given that
LoadOffset + LoadSize > LoadOffset when LoadSize > 0. Thus, this shows
StoreOffset + StoreSize > LoadOffset is guaranteed given LoadSize > 0,
while it could be meaningless to have a type with nonpositive size, so that
the check could be removed. The values are converted to signed types to
avoid unsigned operation with negative offsets.

Part of revision D100179
Reapply commit c35e8185d8c170c20e28956e0c9f3c1be895fefb with fixing problem
reported by mstorsjo

show more ...

Revert "[GVN][NFC] Remove redundant check"

This reverts commit c35e8185d8c170c20e28956e0c9f3c1be895fefb.

mstorsjo reported in the revision thread that one VNCoercion assertion
is violated and seeml

Revert "[GVN][NFC] Remove redundant check"

This reverts commit c35e8185d8c170c20e28956e0c9f3c1be895fefb.

mstorsjo reported in the revision thread that one VNCoercion assertion
is violated and seemly in relate to this commit. As per "If a test case
that demonstrates a problem is reported in the commit thread, please
revert and investigate offline", this commit is reverted.

show more ...

[GVN][NFC] Remove redundant check

The if-check above deleted part guarantees that StoreOffset <= LoadOffset
and that StoreOffset + StoreSize >= LoadOffset + LoadSize, and given that
LoadOffset + L

[GVN][NFC] Remove redundant check

The if-check above deleted part guarantees that StoreOffset <= LoadOffset
and that StoreOffset + StoreSize >= LoadOffset + LoadSize, and given that
LoadOffset + LoadSize > LoadOffset when LoadSize > 0. Thus, this shows
StoreOffset + StoreSize > LoadOffset is guaranteed given LoadSize > 0,
while it could be meaningless to have a type with nonpositive size, so that
the check could be removed.

Part of revision D100179
Reviewed By: nikic

show more ...

[ConstantFolding] Accept offset in ConstantFoldLoadFromConstPtr (NFCI)

As this API is now internally offset-based, we can accept a starting
offset and remove the need to create a temporary bitcast+g

[ConstantFolding] Accept offset in ConstantFoldLoadFromConstPtr (NFCI)

As this API is now internally offset-based, we can accept a starting
offset and remove the need to create a temporary bitcast+gep
sequence to perform an offset load. The API now mirrors the
ConstantFoldLoadFromConst() API.

show more ...

[GVN][NFC] Refactor analyzeLoadFromClobberingWrite

This commit adjusts the order of two swappable if statements to
make code cleaner.

Reviewed By: lattner, nikic
Differential Revision: https://revi

[GVN][NFC] Refactor analyzeLoadFromClobberingWrite

This commit adjusts the order of two swappable if statements to
make code cleaner.

Reviewed By: lattner, nikic
Differential Revision: https://reviews.llvm.org/D99648

show more ...

[VNCoercion] Disallow coercion between different ni addrspaces

I'm not sure if it would be legal by the IR reference to introduce
an addrspacecast here, since the IR reference is a bit vague on
the

[VNCoercion] Disallow coercion between different ni addrspaces

I'm not sure if it would be legal by the IR reference to introduce
an addrspacecast here, since the IR reference is a bit vague on
the exact semantics, but at least for our usage of it (and I
suspect for many other's usage) it is not. For us, addrspacecasts
between non-integral address spaces carry frontend information that the
optimizer cannot deduce afterwards in a generic way (though we
have frontend specific passes in our pipline that do propagate
these). In any case, I'm sure nobody is using it this way at
the moment, since it would have introduced inttoptrs, which
are definitely illegal.

Fixes PR38375

Co-authored-by: Keno Fischer <keno@alumni.harvard.edu>

Reviewed By: reames

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

show more ...

[GVN] small improvements to comments

[gvn] Handle a corner case w/vectors of non-integral pointers

If we try to coerce a vector of non-integral pointers to a narrower type (either narrower vector or single pointer), we use inttoptr and

[gvn] Handle a corner case w/vectors of non-integral pointers

If we try to coerce a vector of non-integral pointers to a narrower type (either narrower vector or single pointer), we use inttoptr and violate the semantics of non-integral pointers. In theory, we can handle many of these cases, we just need to use a different code idiom to convert without going through inttoptr and back.

This shows up as wrong code bugs, and in some cases, crashes due to failed asserts. Modeled after a change which has lived downstream for a couple years, though completely rewritten to be more idiomatic.

show more ...

[NFC] Remove unused GetUnderlyingObject paramenter

Depends on D84617.

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

[NFC] GetUnderlyingObject -> getUnderlyingObject

I am going to touch them in the next patch anyway

[GVN] teach ConstantFolding correct handling of non-integral addrspace casts

Here we teach the ConstantFolding analysis pass that it is not legal to
replace a load of a bitcast constant (having a no

[GVN] teach ConstantFolding correct handling of non-integral addrspace casts

Here we teach the ConstantFolding analysis pass that it is not legal to
replace a load of a bitcast constant (having a non-integral addrspace)
with a bitcast of the value of that constant (with a different
non-integral addrspace).

But also teach it that certain bit patterns are always known and
convertable (a fact it already uses elsewhere). This required us to also
fix a globalopt test, since, after this change, LLVM is able to realize
that the test actually is a valid transform (NULL is always a known
bit-pattern) and so it doesn't need to emit the failure remarks for it.

Also simplify some of the negative tests for transforms by avoiding a
type change in their bitcast, and add positive versions of the same
tests, to show that they otherwise should work.

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

show more ...

[VNCoercion] avoid creating bitcast for zero offsets [NFCI]

This could previously make it more complicated for ConstantFolding
later, leading to a higher likelyhood it would have to reject the
expre

[VNCoercion] avoid creating bitcast for zero offsets [NFCI]

This could previously make it more complicated for ConstantFolding
later, leading to a higher likelyhood it would have to reject the
expression, even though zero seems like probably the common case here.

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

show more ...

VNCoercion.cpp - remove unused includes. NFC.