Take memset_inline into account in analyzeLoadFromClobberingMemInst

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

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

(cherry picked

Take memset_inline into account in analyzeLoadFromClobberingMemInst

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

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

(cherry picked from commit 1a726cfa83667585dd87a9955ed5e331cad45d18)

show more ...

[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 <[email protected]>

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.

[SVE] Remove calls to isScalable from Transforms

Reviewers: efriedma, chandlerc, reames, aprantl, sdesmalen

Reviewed By: efriedma

Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits

T

[SVE] Remove calls to isScalable from Transforms

Reviewers: efriedma, chandlerc, reames, aprantl, sdesmalen

Reviewed By: efriedma

Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits

Tags: #llvm

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

show more ...

[NFC] Use VectorType::isScalable to align with ongoing VectorType refactor.

[GVN] Fix VNCoercion for Scalable Vector.

Summary:
For VNCoercion, skip scalable vector when analysis rely on fixed size,
otherwise call TypeSize::getFixedSize() explicitly.

Add unit tests to check

[GVN] Fix VNCoercion for Scalable Vector.

Summary:
For VNCoercion, skip scalable vector when analysis rely on fixed size,
otherwise call TypeSize::getFixedSize() explicitly.

Add unit tests to check funtionality of GVN load elimination for scalable type.

Reviewers: sdesmalen, efriedma, spatel, fhahn, reames, apazos, ctetreau

Reviewed By: efriedma

Subscribers: bjope, hiraditya, jfb, llvm-commits

Tags: #llvm

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

show more ...

[NFC] Modernize misc. uses of Align/MaybeAlign APIs.

Use the current getAlign() APIs where it makes sense, and use Align
instead of MaybeAlign when we know the value is non-zero.

[VNCoercion] Use IRBuilderBase; NFC

And remove include from header.

[ConstantFolding] Always return something from ConstantFoldConstant

Spin-off from D75407. As described there, ConstantFoldConstant()
currently returns null for non-ConstantExpr/ConstantVector inputs

[ConstantFolding] Always return something from ConstantFoldConstant

Spin-off from D75407. As described there, ConstantFoldConstant()
currently returns null for non-ConstantExpr/ConstantVector inputs,
but otherwise always returns non-null, independently of whether
any folding has happened or not.

This is confusing and makes consumer code more complicated.
I would expect either that ConstantFoldConstant() returns only if
it actually folded something, or that it always returns non-null.
I'm going to the latter possibility here, which appears to be more
useful considering existing usage.

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

show more ...

[MemDepAnalysis/VNCoercion] Move static method to its only use. [NFCI]

Static method MemoryDependenceResults::getLoadLoadClobberFullWidthSize
does not have or use any info specific to MemoryDependen

[MemDepAnalysis/VNCoercion] Move static method to its only use. [NFCI]

Static method MemoryDependenceResults::getLoadLoadClobberFullWidthSize
does not have or use any info specific to MemoryDependenceResults.
Move it to its only user: VNCoercion.

show more ...