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>
Some tools with a specified target arch, but no full triple default to
the host triple. On macos hosts, this would then force using macho on
targets that didn't expect it, resulting in assertions.
We should also probably emit explicit errors if the object format is
specified on targets which don't handle it.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
Neoverse N2 was incorrectly marked as an Armv8.5a core. This has been
changed to an Armv9.0a core. However, crypto options are not enabled
by default for Armv9 cores, so -mcpu=neoverse-n2+crypto is required
to enable crypto for this core.
Neoverse N2 Technical Reference Manual:
https://developer.arm.com/documentation/102099/0003/
We pretended they were v8.5a in the past because LLVM's modelling used
to fold SM4 crypto support into v8.6a (which the CPUs don't actually
have). That's changed in the last year so we can use the real value.
This is mostly a tidy-up commit before one that'll bring in A17 and M3.
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.
The removal started at https://reviews.llvm.org/D50989 and
https://reviews.llvm.org/D75494 removed the Triple support. Without recognizing
Darwin triples as Mach-O, we will get assertion error in ToolChains/Darwin.h due
to the universal binary mechanism.
Fix#47698
---
This requires fixing many misuses of llc -march= and llvm-mc -arch= (
commits 806761a762 and 252c42354e).
Clang implements SPIR-V with both Physical32 and Physical64 addressing
models. This commit adds a new triple value for the Logical
addressing model.
Differential Revision: https://reviews.llvm.org/D155978
This follows the RISC-V work done in
4b40ced4e5.
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.
After this D108637 and with FreeBSD -current and now 14 dropping support for
CloudABI I think it is time to consider deleting the CloudABI support.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D158920
After looking at this further I think the Ananas support should be removed.
They stopped using Clang. There have never been any releases either; as in
source only, and the backend is not maintained.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D158946
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
