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

Identified with misc-include-cleaner.

[VFABI] Move the Vector ABI demangling utility to LLVMCore. (#77513)

This fixes #71892 allowing us to check magled names in the IR verifier.

[TLI] Use the VFABI demangling when declaring vector variants. (#76753)

When creating a declaration for a vector variant, in order to determine
the argument types we need to consult the VFABI deman

[TLI] Use the VFABI demangling when declaring vector variants. (#76753)

When creating a declaration for a vector variant, in order to determine
the argument types we need to consult the VFABI demangler. This will
allow us to add TLI mappings with linear arguments (see #76060).

show more ...

[TLI] Added a guard for empty vector function name. (#68100)

A guard for empty vector function name was removed in #66656. This patch
adds the guard back.

Fix mechanism propagating mangled names for TLI function mappings (#66656)

Currently the mappings from TLI are used to generate the list of
available "scalar to vector" mappings attached to scalar

Fix mechanism propagating mangled names for TLI function mappings (#66656)

Currently the mappings from TLI are used to generate the list of
available "scalar to vector" mappings attached to scalar calls as
"vector-function-abi-variant" LLVM IR attribute. Function names from TLI
are wrapped in mangled name following the pattern:
_ZGV<isa><mask><vlen><parameters>_<scalar_name>[(<vector_redirection>)]
The problem is the mangled name uses _LLVM_ as the ISA name which
prevents the compiler to compute vectorization factor for scalable
vectors as it cannot make any decision based on the _LLVM_ ISA. If we
use "s" as the ISA name, the compiler can make decisions based on VFABI
specification where SVE spacific rules are described.

This patch is only a refactoring stage where there is no change to the
compiler's behaviour.

show more ...

Remove some includes that shouldn't be needed any longer

This remove a bunch of #include statements in Scalar.cpp. I do not
think those should be needed any longer (assuming that they once
upon a ti

Remove some includes that shouldn't be needed any longer

This remove a bunch of #include statements in Scalar.cpp. I do not
think those should be needed any longer (assuming that they once
upon a time possibly were needed for legacy PM C bindings, but
that is not supported any longer).

Also removing some other #include statements not needed any longer
due to deprecation of legacy PM.

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

show more ...

[LegacyPM] Remove InjectTLIMappings and AssumeSimplify passes

[Passes] Remove the legacy DemandedBitsWrapperPass

Last user of DemandedBitsWrapperPass was the BDCE pass. Since
the legacy PM version of BDCE was removed in an earlier commit, this
patch removes th

[Passes] Remove the legacy DemandedBitsWrapperPass

Last user of DemandedBitsWrapperPass was the BDCE pass. Since
the legacy PM version of BDCE was removed in an earlier commit, this
patch removes the now unused DemandedBitsWrapperPass.

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

show more ...

[TLI][AArch64] Extend SLEEF vectorized functions mapping with VLA functions

This commit extends D134719 "[AArch64] Enable libm vectorized
functions via SLEEF" with the mappings for the scalable func

[TLI][AArch64] Extend SLEEF vectorized functions mapping with VLA functions

This commit extends D134719 "[AArch64] Enable libm vectorized
functions via SLEEF" with the mappings for the scalable functions.

It also introduces all the necessary changes needed to support masked
interfaces.

Reviewed By: danielkiss, sdesmalen

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

show more ...

Revert "[TLI][AArch64] Extend SLEEF vectorized functions mapping with VLA functions"

Reverting it so I could land it with Arcanist.

This reverts commit 59dcf927ee43e995374907b6846b657f68d7ea49.

[TLI][AArch64] Extend SLEEF vectorized functions mapping with VLA functions

This commit extends D134719 "[AArch64] Enable libm vectorized
functions via SLEEF" with the mappings for the scalable func

[TLI][AArch64] Extend SLEEF vectorized functions mapping with VLA functions

This commit extends D134719 "[AArch64] Enable libm vectorized
functions via SLEEF" with the mappings for the scalable functions.

It also introduces all the necessary changes needed to support masked
interfaces.

Signed-off-by: Paul Osmialowski <pawel.osmialowski@arm.com>

show more ...

Cleanup includes: TransformsUtils

Estimation on the impact on preprocessor output:
before: 1065307662
after: 1064800684

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

Cleanup includes: TransformsUtils

Estimation on the impact on preprocessor output:
before: 1065307662
after: 1064800684

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

show more ...

[Transforms] Migrate from getNumArgOperands to arg_size (NFC)

Note that getNumArgOperands is considered a legacy name. See
llvm/include/llvm/IR/InstrTypes.h for details.

[llvm] Migrate from arg_operands to args (NFC)

Note that arg_operands is considered a legacy name. See
llvm/include/llvm/IR/InstrTypes.h for details.

[NFC][Analysis] Change struct VecDesc to use ElementCount

This patch changes the VecDesc struct to use ElementCount
instead of an unsigned VF value, in preparation for
future work that adds support

[NFC][Analysis] Change struct VecDesc to use ElementCount

This patch changes the VecDesc struct to use ElementCount
instead of an unsigned VF value, in preparation for
future work that adds support for vectorized versions of
math functions using scalable vectors. Since all I'm doing
in this patch is switching the type I believe it's a
non-functional change. I changed getWidestVF to now return
both the widest fixed-width and scalable VF values, but
currently the widest scalable value will be zero.

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

show more ...

[Analysis] Change VFABI::mangleTLIVectorName to use ElementCount

Adds support for mangling TLI vector names for scalable vectors.

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

[NFC] Reduce include files dependency.

1. Removed #include "...AliasAnalysis.h" in other headers and modules.
2. Cleaned up includes in AliasAnalysis.h.

Reviewed By: RKSimon

Differential Revision:

[NFC] Reduce include files dependency.

1. Removed #include "...AliasAnalysis.h" in other headers and modules.
2. Cleaned up includes in AliasAnalysis.h.

Reviewed By: RKSimon

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

show more ...

[InjectTLIMappings] Use StringRef instead of std::string for FN name.

https://reviews.llvm.org/D83797

Preserve GlobalsAA analysis result in InjectTLIMappings

InjectTLIMappings fails to preserve the analysis result of GlobalsAA. Not preserving the analysis might affect benchmark performance. This cha

Preserve GlobalsAA analysis result in InjectTLIMappings

InjectTLIMappings fails to preserve the analysis result of GlobalsAA. Not preserving the analysis might affect benchmark performance. This change fixes this issue.

Patch by: Ryan Santhiraraja <rsanthir@quicinc.com>

Reviewers: fpetrogalli, joerg, fhahn

Reviewed By: fhahn

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

show more ...

[VectorUtils] Expose vector-function-abi-variant mangling as a utility.

Summary:
This change exposes the vector name mangling with LLVM ISA (used as part
of vector-function-abi-variant) as a utility

[VectorUtils] Expose vector-function-abi-variant mangling as a utility.

Summary:
This change exposes the vector name mangling with LLVM ISA (used as part
of vector-function-abi-variant) as a utility.
This can then be used by front-ends that add this attribute.
Note that all parameters passed in to the function will be mangled with
the "v" token to identify that they are of of vector type. So, it is the
responsibility of the caller to confirm that all parameters in the
vectorized variant is of vector type.

Added unit test to show vector name mangling.

Reviewed-By: fpetrogalli, simoll

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

show more ...

[VectorUtils] Move ToVectorTy to VectorUtils.h (NFC).

ToVectorTy is defined and used in multiple places. Hoist it to
VectorUtils.h to avoid duplication and improve re-usability.

Reviewers: rengolin

[VectorUtils] Move ToVectorTy to VectorUtils.h (NFC).

ToVectorTy is defined and used in multiple places. Hoist it to
VectorUtils.h to avoid duplication and improve re-usability.

Reviewers: rengolin, hsaito, Ayal, gilr, fpetrogalli

Reviewed By: fpetrogalli

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

show more ...

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...

[VectorUtils] Rework the Vector Function Database (VFDatabase).

Summary:
This commits is a rework of the patch in
https://reviews.llvm.org/D67572.

The rework was requested to prevent out-of-tree pe

[VectorUtils] Rework the Vector Function Database (VFDatabase).

Summary:
This commits is a rework of the patch in
https://reviews.llvm.org/D67572.

The rework was requested to prevent out-of-tree performance regression
when vectorizing out-of-tree IR intrinsics. The vectorization of such
intrinsics is enquired via the static function `isTLIScalarize`. For
detail see the discussion in https://reviews.llvm.org/D67572.

Reviewers: uabelho, fhahn, sdesmalen

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

show more ...

Revert "[VectorUtils] Introduce the Vector Function Database (VFDatabase)."

This reverts commit 0be81968a283fd4161cb9ac9748d5ed200926292.

The VFDatabase needs some rework to be able to handle vecto

Revert "[VectorUtils] Introduce the Vector Function Database (VFDatabase)."

This reverts commit 0be81968a283fd4161cb9ac9748d5ed200926292.

The VFDatabase needs some rework to be able to handle vectorization
and subsequent scalarization of intrinsics in out-of-tree versions of
the compiler. For more details, see the discussion in
https://reviews.llvm.org/D67572.

show more ...

[VectorUtils] Introduce the Vector Function Database (VFDatabase).

This patch introduced the VFDatabase, the framework proposed in
http://lists.llvm.org/pipermail/llvm-dev/2019-June/133484.html. [*]

[VectorUtils] Introduce the Vector Function Database (VFDatabase).

This patch introduced the VFDatabase, the framework proposed in
http://lists.llvm.org/pipermail/llvm-dev/2019-June/133484.html. [*]

In this patch the VFDatabase is used to bridge the TargetLibraryInfo
(TLI) calls that were previously used to query for the availability of
vector counterparts of scalar functions.

The VFISAKind field `ISA` of VFShape have been moved into into VFInfo,
under the assumption that different vector ISAs may provide the same
vector signature. At the moment, the vectorizer accepts any of the
available ISAs as long as the signature provided by the VFDatabase
matches the one expected in the vectorization process. For example,
when targeting AVX or AVX2, which both have 256-bit registers, the IR
signature of the two vector functions associated to the two ISAs is
the same. The `getVectorizedFunction` method at the moment returns the
first available match. We will need to add more heuristics to the
search system to decide which of the available version (TLI, AVX,
AVX2, ...) the system should prefer, when multiple versions with the
same VFShape are present.

Some of the code in this patch is based on the work done by Sumedh
Arani in https://reviews.llvm.org/D66025.

[*] Notice that in the proposal the VFDatabase was called SVFS. The
name VFDatabase is more in line with LLVM recommendations for
naming classes and variables.

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

show more ...