This patch adds the feature flags of SME_F8F16 and SME_F8F32,
and the assembly/disassembly for the following instructions of SME2:
* SME:
- FMLAL, FMLALL
- FVDOT, FVDOTT
- FVDOTB
- FMOPA
That is according to this documentation:
https://developer.arm.com/documentation/ddi0602/2023-09
Co-authored-by: Caroline Concatto <caroline.concatto@arm.com>
This patch adds the feature flags of LUT and SME_LUTv2, and the
assembly/disassembly
for the following instructions of NEON, SVE2 and SME2:
* NEON:
- LUT2
- LUT4
* SVE2:
- LUTI2_ZZZI
- LUTI4_ZZZI
- LUTI4_Z2ZZI
* SME:
- MOVT
- LUTI4_4ZZT2Z
- LUTI4_S_4ZZT2Z
That is according to this documentation:
https://developer.arm.com/documentation/ddi0602/2023-09
This patch adds the feature flag FDOT2/FDOT4 and the
assembly/disassembly
for the following instructions of NEON and SVE2:
* NEON:
- FDOTlane
- FDOT
* SVE2:
- FDOT_ZZZI_BtoH
- FDOT_ZZZ_BtoH
- FDOT_ZZZI_BtoS
- FDOT_ZZZ_BtoS
That is according to this documentation:
https://developer.arm.com/documentation/ddi0602/2023-09
…mbly.
This patch adds the feature flag FAMINMAX and the assembly/disassembly
for the following instructions of NEON, SVE2 and SME2:
* NEON:
- FAMIN
- FAMAX
* SVE2:
- FAMIN_ZPmZ
- FAMAX_ZPmZ
* SME2:
- FAMAX_2Z2Z
- FAMIN_2Z2Z
- FAMAX_4Z4Z
- FAMIN_4Z4Z
That is according to this documentation:
https://developer.arm.com/documentation/ddi0602/2023-09
Co-authored-by: Caroline Concatto <caroline.concatto@arm.com>
```
$ ./bin/clang --target=arm-linux-gnueabihf --print-supported-extensions
<...>
All available -march extensions for ARM
crc
crypto
sha2
aes
dotprod
<...>
```
This follows the format set by RISC-V and AArch64. As for AArch64, ARM
doesn't have versioned extensions like RISC-V does. So there is only 1
column, which contains the name.
Any extension without a "feature" is hidden as these cannot be used with
-march.
This follows the RISC-V work done in
4b40ced4e5ba10b841516b3970e7699ba8ded572.
This uses AArch64's target parser instead. We just list the names,
without the "+" on them, which matches RISC-V's format.
```
$ ./bin/clang -target aarch64-linux-gnu --print-supported-extensions
clang version 18.0.0 (https://github.com/llvm/llvm-project.git 154da8aec20719c82235a6957aa6e461f5a5e030)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: <...>
All available -march extensions for AArch64
aes
b16b16
bf16
brbe
crc
crypto
cssc
<...>
```
Since our extensions don't have versions in the same way there's just
one column with the name in.
Any extension without a feature name (including the special "none") is
not listed as those cannot be passed to -march, they're just for the
backend. For example the MTE extension can be added with "+memtag" but
MTE2 and MTE3 do not have feature names so they cannot be added to
-march.
This does not attempt to tackle the fact that clang allows invalid
combinations of AArch64 extensions, it simply lists the possible
options. It's still up to the user to ask for something sensible.
Equally, this has no context of what CPU is being selected. Neither does
the RISC-V option, the user has to be aware of that.
I've added a target parser test, and a high level clang test that checks
RISC-V and AArch64 work and that Intel, that doesn't support this, shows
the correct error.
This implements support for two new 2022 A-profile extensions:
- FEAT_CHK - Check Feature Status Extension
- FEAT_GCS - Guarded Control Stacks
FEAT_CHK is mandatory from armv8.0-a, but is in the hint space so
there's no clang command-line flag for it, and we only print the hint as
`chkfeat x16` at v8.9a and above, to be compatible when using a
non-integrated assembler that might not yet know about the extension.
FEAT_GCS is optional from armv9.4-a onwards. It is enabled using `+gcs`
in a clang `-march=` or `-mcpu=` option string, or using a
`.arch_extension gcs` assembly directive.
This patch includes changes by Ties Stuij, Tomas Matheson, and Keith
Walker.
Differential Revision: https://reviews.llvm.org/D145563
This replaces AEK_CRYPTO in the AArch64TargetParser definitions,
replacing the composite Crypto features with the constituent parts.
AEK_CRYPTO is replaced with either AEK_AES | AEK_SHA2 or AEK_AES |
AEK_SHA2 | AEK_SHA3 | AEK_SHA4 depending on if the cpu is Arm-v8.4+.
This helps get the features correct in some more places like
target(cpu=..) attributes.
Otherwise this is hopefully an NFC for -mcpu options but seems like a
cleaner design.
Differential Revision: https://reviews.llvm.org/D142548
This updates the AArch64's Target Parser and its uses to capture
information about default features directly from ArchInfo and CpuInfo
objects, instead of relying on an API function to access them
indirectly.
Reviewed By: tmatheson
Differential Revision: https://reviews.llvm.org/D142540
This updates the parsing methods in AArch64's Target Parser to make use
of optional returns instead of "invalid" enum values, making the API's
behaviour clearer.
Reviewed By: lenary, tmatheson
Differential Revision: https://reviews.llvm.org/D142539
The CPUs never supported SM4 instructions, but until recently I think crypto
was folded into the baseline architecture as a monolithic feature so it was
difficult to represent that. Now it's split we can, and the CPUs that support
v8.4 onwards only handle AES, SHA2, SHA3 by way of crypto instructions.
The Ampere1A core improves on the Ampere1 with key differences being:
* memory tagging is supported
* SM3/SM4 are supported
* adds a new fusion pair for (A+B+1 and A-B-1)
(added in a later commit)
Depends on D142395
Reviewed By: dmgreen
Differential Revision: https://reviews.llvm.org/D142396
The original enablement for the Ampere1 core inadvertently had omitted
that FEAT_RAND is support and errorously claimed that FEAT_MTE was
available.
Adjust the definition of Ampere1 to match reality.
Reviewed By: dmgreen
Differential Revision: https://reviews.llvm.org/D142395
The Armv8.6-a and later architecture definitions included AES, SHA2,
SHA3 and SM4, but this did not have an effect when specifying
-march=armv8.6-a. The did not set preprocessor features
(https://godbolt.org/z/1YKad6M8e) or enable the relevant instructions
(like eor3 from sha3: https://godbolt.org/z/vY9v4MqvG). Similarly
architectures armv8 to armv8.5 defined +crypto, but this did not effect
the -march's, only the -mcpu with those architectures. I believe this
was working as intended.
After D141411 we now add the default features for architectures except
for +crypto, which has had the effect of enabling aes/sha2/sha3/sm4 when
-march=armv8.6-a is used. This patch removed those crypto features
again, going back to how things were before. It also removes the
AEK_CRYPTO feature from lower architecture levels, moving it to the cpus
that use it. This shouldn't make any changes, but a few extra tests have
been added for preprocessor features that have improved since llvm 15.
The -mcpu=ampere1 cpu is the only armv8.6+ cpu at present. For that, the
AES, SHA2 and SHA3 features have been re-added to the CPU definition to
keep it in-line with the gcc definition from
db2f5d6612.
Differential Revision: https://reviews.llvm.org/D141606
This introduces command line support (`+ite`) for the v9.4-A's
Instrumentation Extension (FEAT_ITE).
Patch by Son Tuan Vu.
Reviewed By: lenary, tmatheson
Differential Revision: https://reviews.llvm.org/D141403
As Armv9-a implies SVE2 it implies SVE (added in D141411) and so it
should also imply FP16, which this patch adds. This helps get the target
features correct when using `target("arch=armv9-a")` attributes.
There is also an adjustment to AssertSameExtensionFlags in this patch to
make it print cpu names, useful when the TargetParser unit tests are run
through lit to distinguish which cpu is failing.
Differential Revision: https://reviews.llvm.org/D142087
Reworked after several other major changes to the TargetParser since
this was reverted. Combined with several other changes.
Inline calls for the following macros and delete AArch64TargetParser.def:
AARCH64_ARCH, AARCH64_CPU_NAME, AARCH64_CPU_ALIAS, AARCH64_ARCH_EXT_NAME
Squashed changes from D139278 and D139102.
Differential Revision: https://reviews.llvm.org/D138792
This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
component into a new LLVM Component called "TargetParser". This
potentially enables using tablegen to maintain this information, as
is shown in https://reviews.llvm.org/D137517. This cannot currently
be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
information in the TargetParser:
- `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
the current Host machine for info about it, primarily to support
getting the host triple, but also for `-mcpu=native` support in e.g.
Clang. This is fairly tightly intertwined with the information in
`X86TargetParser.h`, so keeping them in the same component makes
sense.
- `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
the target triple parser and representation. This is very intertwined
with the Arm target parser, because the arm architecture version
appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.
And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM
Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.
If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.
Differential Revision: https://reviews.llvm.org/D137838
