[FMV][GlobalOpt] Statically resolve calls to versioned functions. (#87939)

To deduce whether the optimization is legal we need to compare the target
features between caller and callee versions. The

[FMV][GlobalOpt] Statically resolve calls to versioned functions. (#87939)

To deduce whether the optimization is legal we need to compare the target
features between caller and callee versions. The criteria for bypassing
the resolver are the following:

* If the callee's feature set is a subset of the caller's feature set,
then the callee is a candidate for direct call.

* Among such candidates the one of highest priority is the best match
and it shall be picked, unless there is a version of the callee with
higher priority than the best match which cannot be picked from a
higher priority caller (directly or through the resolver).

* For every higher priority callee version than the best match, there
is a higher priority caller version whose feature set availability
is implied by the callee's feature set.

Example:

Callers and Callees are ordered in decreasing priority.
The arrows indicate successful call redirections.

Caller Callee Explanation
=========================================================================
mops+sve2 --+--> mops all the callee versions are subsets of the
| caller but mops has the highest priority
|
mops --+ sve2 between mops and default callees, mops wins

sve sve between sve and default callees, sve wins
but sve2 does not have a high priority caller

default -----> default sve (callee) implies sve (caller),
sve2(callee) implies sve (caller),
mops(callee) implies mops(caller)

show more ...

[Clang][LLVM][AArch64]Add new feature SSVE-BitPerm (#121947)

The 20204-12 ISA update release adds a new feature: FEAT_SSVE_BitPerm,
which allows the sve-bitperm instructions to run in streaming mod

[Clang][LLVM][AArch64]Add new feature SSVE-BitPerm (#121947)

The 20204-12 ISA update release adds a new feature: FEAT_SSVE_BitPerm,
which allows the sve-bitperm instructions to run in streaming mode.

It also removes the requirement of FEAT_SVE2 for FEAT_SVE_BitPerm. The
sve2-bitperm feature is now an alias for sve-bitperm and sve2.

A new feature flag sve-bitperm is added to reflect the change that the
instructions under FEAT_SVE_BitPerm are supported if:
on non streaming mode with FEAT_SVE2 and FEAT_SVE_BitPerm or
in streaming mode with FEAT_SME and FEAT_SSVE_BitPerm

show more ...

[FMV][AArch64] Simplify version selection according to ACLE. (#121921)

Currently, the more features a version has, the higher its priority is.
We are changing ACLE https://github.com/ARM-software/a

[FMV][AArch64] Simplify version selection according to ACLE. (#121921)

Currently, the more features a version has, the higher its priority is.
We are changing ACLE https://github.com/ARM-software/acle/pull/370 as
follows:

"Among any two versions, the higher priority version is determined by
identifying the highest priority feature that is specified in exactly
one of the versions, and selecting that version."

show more ...

[AArch64][FMV] Add missing feature dependencies and detect at runtime. (#119231)

i8mm -> simd
fp16fml -> simd
frintts -> fp
bf16 -> simd
sme -> fp16

Approved in ACLE as https://github.com/ARM

[AArch64][FMV] Add missing feature dependencies and detect at runtime. (#119231)

i8mm -> simd
fp16fml -> simd
frintts -> fp
bf16 -> simd
sme -> fp16

Approved in ACLE as https://github.com/ARM-software/acle/pull/368

show more ...

[NFC][clang][FMV][TargetInfo] Refactor API for FMV feature priority. (#116257)

Currently we have code with target hooks in CodeGenModule shared between
X86 and AArch64 for sorting MultiVersionResol

[NFC][clang][FMV][TargetInfo] Refactor API for FMV feature priority. (#116257)

Currently we have code with target hooks in CodeGenModule shared between
X86 and AArch64 for sorting MultiVersionResolverOptions. Those are used
when generating IFunc resolvers for FMV. The RISCV target has different
criteria for sorting, therefore it repeats sorting after calling
CodeGenFunction::EmitMultiVersionResolver.

I am moving the FMV priority logic in TargetInfo, so that it can be
implemented by the TargetParser which then makes it possible to query it
from llvm. Here is an example why this is handy:
https://github.com/llvm/llvm-project/pull/87939

show more ...

[AArch64] Make +sve2-aes an alias of +sve2+sve-aes (#116026)

This patch essentially re-lands
https://github.com/llvm/llvm-project/pull/114293 with the following
fixups

- `nosve2-aes` should dis

[AArch64] Make +sve2-aes an alias of +sve2+sve-aes (#116026)

This patch essentially re-lands
https://github.com/llvm/llvm-project/pull/114293 with the following
fixups

- `nosve2-aes` should disable the backend feature `FeatureSVEAES` such
that the set of existing instructions that this removes is unchanged.
- FMV dependencies now use the autogenerated `ExtensionDepencies`
structure (since https://github.com/llvm/llvm-project/pull/113281) so we
do not require the change to `AArch64FMV.td`.

show more ...

[llvm][AArch64][TableGen] Create a ProcessorAlias record (#96249)

... and use it to organize all of the AArch64 CPU aliases.

Re-land: "[AArch64] Add ability to list extensions enabled for a target" (#95805) (#96795)

This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list

Re-land: "[AArch64] Add ability to list extensions enabled for a target" (#95805) (#96795)

This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list of extensions that are enabled for the
target specified by the combination of `--target`/`-march`/`-mcpu`
values.

The goal of the this option is both to enable the manual inspection of
the enabled extensions by users and to enhance the testability of
architecture versions and CPU targets implemented in the compiler.

As part of this change, a new field for `FEAT_*` architecture feature
names was added to the TableGen entries. The output of the existing
`--print-supported-extensions` option was updated accordingly to show
these in a separate column.

show more ...

Revert "[AArch64] Add ability to list extensions enabled for a target" (#96768)

Reverts llvm/llvm-project#95805 due to test failures caught by the
buildbots.

[AArch64] Add ability to list extensions enabled for a target (#95805)

This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list of extensions that

[AArch64] Add ability to list extensions enabled for a target (#95805)

This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list of extensions that are enabled for the
target specified by the combination of `--target`/`-march`/`-mcpu`
values.

The goal of the this option is both to enable the manual inspection of
the enabled extensions by users and to enhance the testability of
architecture versions and CPU targets implemented in the compiler.

As part of this change, a new field for `FEAT_*` architecture feature
names was added to the TableGen entries. The output of the existing
`--print-supported-extensions` option was updated accordingly to show
these in a separate column.

show more ...

[AArch64][TargetParser] Split FMV and extensions (#92882)

FMV extensions are really just mappings from FMV feature names to lists
of backend features for codegen. Split them out into their own sepa

[AArch64][TargetParser] Split FMV and extensions (#92882)

FMV extensions are really just mappings from FMV feature names to lists
of backend features for codegen. Split them out into their own separate
file.

show more ...

Reland "[AArch64] Decouple feature dependency expansion. (#94279)" (#95519)

This is the second attempt. When parsing the target attribute
we should be letting cc1 features which don't correspond to

Reland "[AArch64] Decouple feature dependency expansion. (#94279)" (#95519)

This is the second attempt. When parsing the target attribute
we should be letting cc1 features which don't correspond to
Extensions pass through to avoid errors like the following:

% cat neon.c
__attribute__((target("arch=armv8-a")))
uint64x2_t foo(uint64x2_t a, uint64x2_t b) { return veorq_u64(a, b); }

% clang --target=aarch64-linux-gnu -c neon.c
error: always_inline function 'veorq_u64' requires target feature
'outline-atomics', but would be inlined into function 'foo'
that is compiled without support for 'outline-atomics'

Co-authored-by: Tomas Matheson <Tomas.Matheson@arm.com>

show more ...

[AArch64][TargetParser] move CPUInfo into tablegen [NFC] (#92145)

This is a follow up to #92037, which moved the architecture information.

Generate the AArch64TargetParser CPUInfo from tablegen P

[AArch64][TargetParser] move CPUInfo into tablegen [NFC] (#92145)

This is a follow up to #92037, which moved the architecture information.

Generate the AArch64TargetParser CPUInfo from tablegen Processor defs using a
new tablegen emitter. Some basic error checking is added in the emitter to
ensure that duplicate features are not added to the Processor defs.

The generic CPU becomes an entry in tablegen.

Some CPU features which were present in the CPUInfo but absent from the tablegen
defs have been added to tablegen. FeatureCrypto is replaced with FeatureSHA2 and
FeatureAES. This changes a few of the tests.

show more ...

Revert "Reland "[AArch64] Decouple feature dependency expansion. (#94279)" (#95231)"

This reverts commit 70510733af33c70ff7877eaf30d7718b9358a725.

The following code is now incorrectly rejected.

`

Revert "Reland "[AArch64] Decouple feature dependency expansion. (#94279)" (#95231)"

This reverts commit 70510733af33c70ff7877eaf30d7718b9358a725.

The following code is now incorrectly rejected.

```
% cat neon.c
#include <arm_neon.h>
__attribute__((target("arch=armv8-a")))
uint64x2_t foo(uint64x2_t a, uint64x2_t b) {
return veorq_u64(a, b);
}
% newclang --target=aarch64-linux-gnu -c neon.c
neon.c:5:10: error: always_inline function 'veorq_u64' requires target feature 'outline-atomics', but would be inlined into function 'foo' that is compiled without support for 'outline-atomics'
5 | return veorq_u64(a, b);
| ^
1 error generated.
```

"+outline-atomics" seems misleading here.

show more ...

Reland "[AArch64] Decouple feature dependency expansion. (#94279)" (#95231)

My reverted attempt to decouple feature dependency expansion (see
#95056) made it evident that some features are still us

Reland "[AArch64] Decouple feature dependency expansion. (#94279)" (#95231)

My reverted attempt to decouple feature dependency expansion (see
#95056) made it evident that some features are still using the FMV
dependencies in the target attribute.

The original commit broke the llvm test suite. This was addressed here:
https://github.com/llvm/llvm-test-suite/pull/133. I am now relanding it.

show more ...

Revert "[AArch64] Decouple feature dependency expansion. (#94279)" (#95056)

This reverts commit 2cf14398c9341feddb419e7ff9c8c5623a3da3db since it
broke the llvm test suite:

SingleSource/UnitTest

Revert "[AArch64] Decouple feature dependency expansion. (#94279)" (#95056)

This reverts commit 2cf14398c9341feddb419e7ff9c8c5623a3da3db since it
broke the llvm test suite:

SingleSource/UnitTests/AArch64/acle-fmv-features.c:59:9:
error: instruction requires: altnzcv
SingleSource/UnitTests/AArch64/acle-fmv-features.c:117:10:
error: instruction requires: aes
...

Looks like the FMV dependencies were used in the target attribute and
now features that are FMVOnly (have AEK_NONE) cannot be expanded in
parseTargetAttr using the ExtensionSet.

This suggests that either the tests are wrong (they are using an FMVOnly
feature in a target attribute), or that we need to turn the FMVOnly
features into Extensions (these two are tablegen classes).

show more ...

[AArch64] Decouple feature dependency expansion. (#94279)

The dependency expansion step which was introduced by FMV has been
erroneously used for non-FMV features, for example when parsing the
tar

[AArch64] Decouple feature dependency expansion. (#94279)

The dependency expansion step which was introduced by FMV has been
erroneously used for non-FMV features, for example when parsing the
target attribute. The PR #93695 has rectified most of the tests which
were relying on dependency expansion of target features specified on the
-cc1 command line. In this patch I am decoupling the dependency
expansion of features specified on the target attribute from FMV.

To do that first I am expanding FMV dependencies before passing the list
of target features to initFeatureMap(). Similarly when parsing the
target attribute I am reconstructing an ExtensionSet from the list of
target features which was created during the command line option
parsing. The attribute parsing may toggle bits of that ExtensionSet and
at the end it is converted to a list of target features. Those are
passed to initFeatureMap(), which no longer requires an override.

A side effect of this refactoring is that features specified on the
target_version attribute now supersede the command line options, which
is what should be happening in the first place.

show more ...

[AArch64][TargetParser] Move ExtensionDependencies into tablegen [NFC] (#93614)

This patch generates ExtensionDependency pairs {Earlier, Later} inferred
by the 'Implies' field of every Extension de

[AArch64][TargetParser] Move ExtensionDependencies into tablegen [NFC] (#93614)

This patch generates ExtensionDependency pairs {Earlier, Later} inferred
by the 'Implies' field of every Extension defined in tablegen. Implied
Subtarget Features that are not Extensions are skipped.

show more ...

[AArch64][TargetParser] Move extension aliases into tablegen (#91970)

Update FEAT_PAuth_LR behaviour for AArch64 (#90614)

Currently, LLVM enables `-mbranch-protection=standard` as `bti+pac-ret`.
To align LLVM with the behaviour in GNU, this has been updated to
`bti+

Update FEAT_PAuth_LR behaviour for AArch64 (#90614)

Currently, LLVM enables `-mbranch-protection=standard` as `bti+pac-ret`.
To align LLVM with the behaviour in GNU, this has been updated to
`bti+pac-ret+pc` when FEAT_PAuth_LR is enabled as an optional feature
via the `-mcpu=` options. If this is not enabled, then this will revert
to the existing behaviour.

show more ...

[AArch64] Remove Automatic Enablement of FEAT_F32MM (#85203)

When `+sve` is passed in the command line, if the Architecture being
targeted is V8.6A/V9.1A or later, `+f32mm` is also added. This enab

[AArch64] Remove Automatic Enablement of FEAT_F32MM (#85203)

When `+sve` is passed in the command line, if the Architecture being
targeted is V8.6A/V9.1A or later, `+f32mm` is also added. This enables
FEAT_32MM, however at the time of writing no CPU's support this. This
leads to the FEAT_32MM instructions being compiled for CPU's that do not
support them.

This commit removes the automatic enablement, however the option is
still able to be used by passing `+f32mm`.

show more ...

[TargetParser][AArch64] Add alias for FEAT_RDM. (#80540)

This patch allows using the name "rdma" as an alias for "rdm". The name
makes its way to target attributes as well as the command line via t

[TargetParser][AArch64] Add alias for FEAT_RDM. (#80540)

This patch allows using the name "rdma" as an alias for "rdm". The name
makes its way to target attributes as well as the command line via the
-march and -mcpu options. The motivation was originally to support this
in Function Multi Versioning but it also makes sense to align with GCC
on the command line.

show more ...

[llvm][AArch64][TargetParser][NFC] Use parseArchExtension in parseModifier. (#80427)

This allows making changes in parseArchExtension to make their way in
the command line as well, not only in targ

[llvm][AArch64][TargetParser][NFC] Use parseArchExtension in parseModifier. (#80427)

This allows making changes in parseArchExtension to make their way in
the command line as well, not only in target attributes.

show more ...

[AArch64] Fix -Wreturn-type in AArch64TargetParser.cpp (NFC)

llvm-project/llvm/lib/TargetParser/AArch64TargetParser.cpp:157:1:
error: non-void function does not return a value in all control paths [

[AArch64] Fix -Wreturn-type in AArch64TargetParser.cpp (NFC)

llvm-project/llvm/lib/TargetParser/AArch64TargetParser.cpp:157:1:
error: non-void function does not return a value in all control paths [-Werror,-Wreturn-type]
}
^
1 error generated.

show more ...

[AArch64][Driver] Better handling of target feature dependencies (#78270)

Currently there are several bits of code in the AArch64 driver which
attempt to enforce dependencies between optional featu

[AArch64][Driver] Better handling of target feature dependencies (#78270)

Currently there are several bits of code in the AArch64 driver which
attempt to enforce dependencies between optional features in the -march=
and -mcpu= options. However, these are based on the list of feature
names being enabled/disabled, so they have a lot of logic to consider
the order in which features were turned on and off, which doesn't scale
well as dependency chains get longer.

This patch moves the code handling these dependencies to TargetParser,
and changes them to use a Bitset of enabled features. This makes it easy
to check which features are enabled, and is converted back to a list of
LLVM feature names once all of the command-line options are parsed.

The motivating example for this was the -mcpu=cortex-r82+nofp option.
Previously, the code handling the dependency between the fp16 and
fp16fml extensions did not consider the nofp modifier, so it added
+fullfp16 to the feature list. This should have been disabled by the
+nofp modifier, and also the backend did follow the dependency between
fullfp16 and fp, resulting in fp being turned back on in the backend.

Most of the dependencies added to AArch64TargetParser.h weren't known
about by clang before, I built that list by checking what the backend
thinks the dependencies between SubtargetFeatures are.

show more ...