This adds a check that all ExtensionWithMArch which are marked as
implied features for an architecture are also present in the list of
default features. It doesn't make sense to have something mandatory but
not on by default.
There were a number of existing cases that violated this rule, and some
changes to which features are mandatory (indicated by the Implies
field).
This resulted in a bug where if a feature was marked as `Implies` but
was not added to `DefaultExt`, then for `-march=base_arch+nofeat` the
Driver would consider `feat` to have never been added and therefore
would do nothing to disable it (no `-target-feature -feat` would be
added, but the backend would enable the feature by default because of
`Implies`). See
clang/test/Driver/aarch64-negative-modifiers-for-default-features.c.
Note that the processor definitions do not respect the architecture
DefaultExts. These apply only when specifying `-march=<some architecture
version>`. So when a feature is moved from `Implies` to `DefaultExts` on
the Architecture definition, the feature needs to be added to all
processor definitions (that are based on that architecture) in order to
preserve the existing behaviour. I have checked the TRMs for many cases
(see specific commit messages) but in other cases I have just kept the
current behaviour and not tried to fix it.
Implement FEAT_SME_B16B16 to enable ZA-targeting non-widening SME
BFloat16 instructions. Remove the now redundant FEAT_B16B16 which has
been replaced by FEAT_SVE_B16B16 and FEAT_SME_B16B16 (this commit), see
https://github.com/llvm/llvm-project/pull/101480/ for the details and
reasoning of this change to LLVM.
FEAT_SME_B16B16 is documented under the latest Armv9.4 feature
documentation:
https://developer.arm.com/documentation/109697/0100/Feature-descriptions/The-Armv9-4-architecture-extensio
- Changes to Clang AArch64 frontend
- Change target guard of SME2 ZA-targeting non-widening BFloat16
intrinsics to 'sme-b16b16'
- Changes to LLVM AArch64 backend
- llvm/lib/Target/AArch64/AArch64Features.td
- Create FeatureSMEB16B16, which implies FeatureSME2 and
FeatureSVEB16B16
- Remove FeatureB16B16
- Fix description of FeatureSVEB16B16
- llvm/lib/Target/AArch64/AArch64InstrInfo.td
- Create HasSMEB16B16 predicate
- llvm/lib/Target/AArch64/AArch64SMEInstrInfo.td
- Change predictication of SME2 ZA-targeting non-widening BFloat16
instructions to new HasSMEB16B16
- llvm/lib/Target/AArch64/AArch64.td
- Add HasSMEB16B16 to SME2Unsupported (FEAT_SME_B16B16 implies
FEAT_SME2)
- llvm/lib/AArch64/AsmParser/AArch64AsmParser.cpp
- Remove flag 'b16b16' mapping to removed FeatureB16B16
- Add flag 'sme-b16b16' mapping to new FeatureSMEB16B16
- Changes to LLVM unit tests
- llvm/unittests/TargetParser/TargetParserTest.cpp
- Add new sme-b16b16 flag to existing target parser tests
- Add tests for the sme-b16b16 dependencies:
- 'sme-b16b16' should enable 'sme2', 'sve-b16b16'. - Remove 'b16b16'
from bf16 dependency test
- Added MC tests
- llvm/test/MC/AArch64/SME2p1
- To ensure that ZA-targeting multi-vector non-widening BFloat16
instructions are enabled by +sme-b16b16, and that this feature is
removed by +nosme-b61b6.
- Modidified tests
- All CodeGen, Semantic, and MC tests that are effected by the removal
of 'b16b16', have been modified to supply and/or expect 'sme-b16b16'
where appropriate.
This patch adds FeatureSVEB16B16 to the AArch64 backend in order to
represent the new behavior of FEAT_SVE_B16B16 (as described in the
latest [Armv9.4 extensions
documentation](https://developer.arm.com/documentation/109697/0100/Feature-descriptions/The-Armv9-4-architecture-extension?lang=en#md461-the-armv94-architecture-extension__FEAT_SVE_B16B16))
as well as a 'sve-b16b16' flag to enable it.
The predication of non-widening SVE BFloat16 instructions has changed to
require this feature, instead of the previously required and
soon-to-be-removed FeatureB16B16 which is enabled by the 'b16b16' flag.
Therefore, this change weakens the 'b16b16' flag in favour of
'sve-b16b16'. Existing tests that are effected by this have been
modified to use and/or expect 'sve-b16b16', and new tests have been
added to verify the behavior and implementation of 'sve-b16b16'.
This patch is in response to the response to the following changes.
The architecture features previously enabled by FEAT_SVE_B16B16 have
been relaxed such that it now implements:
- With FEAT_SVE2 : SVE non-widening BFloat16 instructions in
Non-streaming SVE mode
- With FEAT_SME2: SVE non-widening BFloat16 instructions when the
PE is in Streaming SVE mode and SME
Z-targeting multi-vector non-widening BFloat16 instructions.
- **It no longer implements** SME ZA-targeting non-widening
BFloat16 instructions.
The SME ZA-targeting non-widening BFloat16 instructions are implemented
by the new FEAT_SME_B16B16, **this patch does not change how this
architecture feature is enabled** ('+b16b16+sme2'). Only those that are
implemented by FEAT_SVE_B16B16 have been changed to require 'sve-b16b16'
instead of 'b16b16'.
New flags must be created to represent FEAT_SVE_B16B16 and
FEAT_SME_B16B16:
- 'sve-b16b16' enables the updated FEAT_SVE_B16B16 (described
here)
- 'sme-b16b16' will enable the new FEAT_SME_B16B16
- **This patch includes 'sve-b16b16' only**
A future patch will add 'sme-b16b16', SME ZA-targeting non-widening
BFloat16 instructions would then be guarded by '+sme-b16b16+sme2', and
'b16b16' can be removed.
We added FPAC recently in d7e8a7487cd7 to allow ptrauth codegen to rely
on the cpu auth failure checks rather than emitting its own auth failure
check/brk sequence.
Add it to the Apple processors that do have it: A15, A16, A17, M4.
While there, tweak the description to refer to Armv8.3-A rather than
v8.3-A, matching the other features.
But since SVE and friends have been added to the default extensions
list, and every CPU was opted into those extensions by default, we
couldn't correctly announce its architecutral version to the backend.
Additionally, we FEAT_MEC from llvm's "required" list for v9.0 to the
optional list for v9.2, as the spec considers it optional, and M4 does
not implement it. Similarly, fixes up several bugs w.r.t. FEAT_RME.
As a drive-by, I noticed that saphira did not have an
AArch64CPUTestParams entry, and thus added one.
For both overloads, we were printing the bit-pattern for ExpectedFlags
twice. While we're here, also add a convenience line that highlights the
difference between the two sets.
For AArch64, we have existing tests for `--print-enabled-extensions` for
each architecture. However:
- These are added to the end of the existing tests which check for
`"-target-feature"`, which complicates them slightly.
- They do not test the descriptions printed next to each feature.
- Part of the output was tested separately in `TargetParserTest`.
- We did not have _any_ tests of this output for CPUs (only for
architectures).
Similarly, the tests for `--print-supported-extensions` do not give
complete coverage of either the full list of features or the
descriptions.
In my opinion we should be testing the full output, as this is what the
user sees. Descriptions and formatting can contain errors and be
accidentally broken.
There were a couple of cases where this field was just plain wrong
because we weren't actually testing against it. Instead, drop the
`CPUAttr` field on AArch64 tests.
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.
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.
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.
This patch removes FEAT_FPMR from list of available of architecture
features, instead enabling FMPR register by default.
Additionally dependencies between architectural features are added and
fixed.
Generate TargetParser extension information from tablegen. This includes FMV extension information. FMV only extensions are represented by a separate tablegen class.
Use MArchName/ArchKindEnumSpelling to avoid renamings.
Cases where there is simply a case difference are handled by
consistently uppercasing the AEK_ name in the emitted code.
Remove some Extensions which were not needed.
These had AEK entries but were never actually used for anything.
They are not present in Extensions[] data.
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.
- StringRef::operator==/!= outnumber StringRef::equals by a factor of
70 under llvm/ in terms of their usage.
- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.
- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".
This was [addressed for AArch64
here](https://github.com/llvm/llvm-project/pull/79004), but the same
applies to ARM.
Move the enablement of neon+fp64 to `-mcpu=cortex-r52`, which optionally
supports these features.
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`.
This is something we generally tend to avoid due to it confusing the git
history, but with the new github formatting bots being more noisy we
keep running into issues with the existing formatting when adding or
adjusting CPUs. This patch formats the code to make sure we are in a
good state going forward.
Correct an issue with Arm Neoverse N2 after it was
changed to a v9a core in change
f576cbe44eabb8a5ac0af817424a0d1e7c8fbf85:
* FEAT_FHM should be enabled for this core.
This reverts commit 89c1bf1230e011f2f0e43554c278205fa1819de5.
This has been unimplemenented for a while, and GCC does not implement
it, therefore we need to consider whether we should just deprecate it
in the ACLE instead.
This patch changes how the macro __ARM_ARCH is defined to match its
defintion in the ACLE. In ACLE 5.4.1, __ARM_ARCH is defined as equal to
the major architecture version for ISAs up to and including v8. From
v8.1 onwards, its definition is changed to include minor versions, such
that for an architecture vX.Y, __ARM_ARCH = X*100 + Y. Before this
patch, LLVM defined __ARM_ARCH using only the major architecture version
for all architecture versions. This patch adds functionality to define
__ARM_ARCH correctly for architectures greater than or equal to v8.1.
The Ampere1B is Ampere's third-generation core implementing a
superscalar, out-of-order microarchitecture with nested virtualization,
speculative side-channel mitigation and architectural support for
defense against ROP/JOP style software attacks.
Ampere1B is an ARMv8.7+ implementation, adding support for the FEAT
WFxT, FEAT CSSC, FEAT PAN3 and FEAT AFP extensions. It also includes all
features of the second-generation Ampere1A, such as the Memory Tagging
Extension and SM3/SM4 cryptography instructions.
Before:
```
[----------] 65 tests from AArch64CPUTests/AArch64CPUTestFixture
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/0
[ OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/0 (0 ms)
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/1
[ OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/1 (0 ms)
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/2
[ OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/2 (0 ms)
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/3
[ OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/3 (0 ms)
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/4
[ OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/4 (0 ms)
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/5
[ OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/5 (0 ms)
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/6
[ OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/6 (0 ms)
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/7
[ OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/7 (0 ms)
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/8
...
```
After:
```
[----------] 65 tests from AArch64CPUTests/AArch64CPUTestFixture
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a34
[ OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a34 (0 ms)
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a35
[ OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a35 (0 ms)
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a53
[ OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a53 (0 ms)
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a55
[ OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a55 (0 ms)
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a510
[ OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a510 (0 ms)
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a520
[ OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a520 (0 ms)
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a57
[ OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a57 (0 ms)
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a65
[ OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a65 (0 ms)
...
```
Which improves the experience of finding and running this:
```
$ ./unittests/TargetParser/TargetParserTests --gtest_filter=AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a65
Note: Google Test filter = AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a65
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from AArch64CPUTests/AArch64CPUTestFixture
[ RUN ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a65
[ OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a65 (0 ms)
[----------] 1 test from AArch64CPUTests/AArch64CPUTestFixture (0 ms total)
[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (0 ms total)
[ PASSED ] 1 test.
```
Add AEK_PAUTH to ARMV8_3A in TargetParser and let it propagate to
ARMV8R, as it aligns with GCC defaults.
After adding AEK_PAUTH, several tests from TargetParserTest.cpp crashed
when trying to format an error message, thus update a format string in
AssertSameExtensionFlags to account for bitmask being pre-formatted as
std::string.
The CHECK-PAUTH* lines in aarch64-target-features.c are updated to
account for the fact that FEAT_PAUTH support and pac-ret can be enabled
independently and all four combinations are possible.
With a690e86 we added -mcpu/mtune=native support to handle the Microsoft
Azure Cobalt 100 CPU as a Neoverse N2. This patch adds a CPU alias in
TargetParser to maintain compatibility with GCC.
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.
This implements assembly support for the Memory Systems Extensions
introduced as part of the Armv9.5-A architecture version.
The changes include:
* New subtarget feature for FEAT_TLBIW.
* New system registers for FEAT_HDBSS:
* HDBSSBR_EL2 and HDBSSPROD_EL2.
* New system registers for FEAT_HACDBS:
* HACDBSBR_EL2 and HACDBSCONS_EL2.
* New TLBI instructions for FEAT_TLBIW:
* VMALLWS2E1(nXS), VMALLWS2E1IS(nXS) and VMALLWS2E1OS(nXS).
* New system register for FEAT_FGWTE3:
* FGWTE3_EL3.
- Adds a new +pc option to -mbranch-protection that will enable
the use of PC as a diversifier in PAC branch protection code.
- When +pauth-lr is enabled (-march=armv9.5a+pauth-lr) in combination
with -mbranch-protection=pac-ret+pc, the new 9.5-a instructions
(pacibsppc, retaasppc, etc) are used.
Documentation for the relevant instructions can be found here:
https://developer.arm.com/documentation/ddi0602/2023-09/Base-Instructions/
Co-authored-by: Lucas Prates <lucas.prates@arm.com>
This introduces assembly support for the Checked Pointer Arithmetic
Extension (FEAT_CPA), annouced as part of the Armv9.5-A architecture
version.
The changes include:
* New subtarget feature for FEAT_CPA
* New scalar instruction for pointer arithmetic
* ADDPT, SUBPT, MADDPT, and MSUBPT
* New SVE instructions for pointer arithmetic
* ADDPT (vectors, predicated), ADDPT (vectors, unpredicated)
* SUBPT (vectors, predicated), SUBPT (vectors, unpredicated)
* MADPT and MLAPT
* New ID_AA64ISAR3_EL1 system register
Mode details about the extension can be found at:
* https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-developments-2023
* https://developer.arm.com/documentation/ddi0602/2023-09/
Co-authored-by: Rodolfo Wottrich <rodolfo.wottrich@arm.com>
