7dc20ab introduced an extra COPY when spilling and filling a PNR
register, which can't be elided as the input (PNR predicate) and output
(PPR predicate) register classes differ. The patch adds a new register
class that covers both PPR and PNR so that STR_PXI and LDR_PXI can
take either of them, removing the need for the copy.
An immediate integer operand not prefixed with # can also be followed
by "lsl". Parse "lsl".
In the wild, edk2 ArmPkg/Include/AsmMacroIoLibV8.h has
`movz Reg, (Val) >> 16, lsl #16`.
Note: our support for paren expression not prefixed with # is not very
good. For example, `adds x3, x4, (1024>>0), lsl 12` fails to be parsed.
Shift and extend modifiers are parsed as separate operands. When a
symbol operand of a branch instruction has such a "bad" name,
AArch64AsmParser will report an error.
```
% cat a.c
void lsl(); void lsr(); void asr(); void ror(); void uxtb(); void sxtx();
void foo() { lsl(); asr(); asr(); ror(); uxtb(); sxtx(); }
% clang --target=aarch64 -c -save-temps a.c
a.s:15:8: error: expected #imm after shift specifier
bl lsl
^
a.s:16:8: error: expected #imm after shift specifier
bl asr
^
a.s:17:8: error: expected #imm after shift specifier
bl asr
^
a.s:18:8: error: expected #imm after shift specifier
bl ror
^
a.s:19:5: error: expected label or encodable integer pc offset
bl uxtb
^
a.s:20:5: error: expected label or encodable integer pc offset
bl sxtx
^
```
In contrast, gas correctly parses these instructions.
Fix#79729 by parsing shift/extend modifier after an immediate
value/register
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.
Add assembly/disassembly support for the new PAuthLR instructions
introduced in Armv9.5-A:
- AUTIASPPC/AUTIBSPPC
- PACIASPPC/PACIBSPPC
- PACNBIASPPC/PACNBIBSPPC
- RETAASPPC/RETABSPPC
- PACM
Documentation for these instructions can be found here:
https://developer.arm.com/documentation/ddi0602/2023-09/Base-Instructions/
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>
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.
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>
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 fixes:
llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp:4575:16:
error: 'ParseStatus' is deprecated: Migrate to ParseStatus
[-Werror,-Wdeprecated-declarations]
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>
…r the assembly disassembly
This NFC patch refactors the assembly/disassembly class and multiclass
in the AArch64 backend to receive a new 2023/09 AArch64[1] ISA release.
The encoding for the 2023 instructions re-uses encoding blocks from
previous assembly/disassembly instructions.
The refactoring makes the class and multiclass for assembly/disassembly
generic so it can be used to describe the instructions for the new ISA.
[1]https://developer.arm.com/documentation/ddi0602/2023-09
This patch separates PNR registers into their own register class instead
of sharing a register class with PPR registers. This primarily allows us
to return more accurate register classes when applying assembly
constraints, but also more protection from supplying an incorrect
predicate type to an invalid register operand.
This finishes the work of replacing OperandMatchResultTy with
ParseStatus, started in D154101.
As a drive-by change, rename some RegNo variables to just Reg
(a leftover from the days when RegNo had 'unsigned' type).
The patch adds parser, MCExpr, and emitter support for the authenticated
pointer auth relocation.
In assembly, this is expressed using:
.quad <symbol>@AUTH(<key>, <discriminator> [, addr])
For example:
.quad _g3@AUTH(ib, 1234, addr)
The optional 'addr' specifier represents whether the generated pointer
authentication code will also include address diversity (by blending the
address of the storage location of the relocated pointer with the
user-specified constant discriminator).
The @AUTH expression lowers to R_AARCH64_AUTH_ABS64 ELF relocation.
The signing schema is encoded in the place of relocation to be applied
as follows:
```
| 63 | 62 | 61:60 | 59:48 | 47:32 | 31:0 |
| ----------------- | -- | ----- | ----- | ------------- | ------ |
| address diversity | 0 | key | 0 | discriminator | addend |
```
See the following for details:
https://github.com/ARM-software/abi-aa/blob/main/pauthabielf64/pauthabielf64.rst#static-relocations
Differential Revision: https://reviews.llvm.org/D156505
Co-authored-by: Ahmed Bougacha <ahmed@bougacha.org>
Co-authored-by: Peter Collingbourne <peter@pcc.me.uk>
ParseStatus is slightly more convenient to use due to implicit
conversion from bool, which allows to do something like:
```
return Error(L, "msg");
```
when with MatchOperandResultTy it had to be:
```
Error(L, "msg");
return MatchOperand_ParseFail;
```
It also has more appropriate name since parse* methods are not only for
parsing operands.
Reviewed By: david-arm
Differential Revision: https://reviews.llvm.org/D154292
SubtargetFeature.h is currently part of MC while it doesn't depend on
anything in MC. Since some LLVM components might have the need to work
with target features without necessarily needing MC, it might be
worthwhile to move SubtargetFeature.h to a different location. This will
reduce the dependencies of said components.
Note that I choose TargetParser as the destination because that's where
Triple lives and SubtargetFeatures feels related to that.
This issues came up during a JITLink review (D149522). JITLink would
like to avoid a dependency on MC while still needing to store target
features.
Reviewed By: MaskRay, arsenm
Differential Revision: https://reviews.llvm.org/D150549
This brings the list of extensions supported here up to date
with what is supported by current git versions of binutils.
Also add a comment to AArch64TargetParser to remind people to
consider adding new ones to the list supported in assembly.
In the case of the "rdma" extension, there's a slight surprise:
LLVM knows of the extension under the name "rdm", while binutils
has it named "rdma". However, binutils appears to accept any
abbreviated prefix of an arch extension, so it does accept the
form "rdm" too even if it formally considers it called "rdma".
Support both spellings for the extensions here, for simplicity.
Differential Revision: https://reviews.llvm.org/D151981
This patch migrates uses of StringRef::{starts,ends}with_insensitive
to StringRef::{starts,ends}_with_insensitive so that we can use names
similar to those used in std::string_view. I'm planning to deprecate
StringRef::{starts,ends}with_insensitive once the migration is
complete across the code base.
Differential Revision: https://reviews.llvm.org/D150426
The LDR and STR instructions must have the same value for imm4(second operand)
and offset(fourth operand).
The disassembly guarantees that happens, but the Asm parser was not checking that.
This patch fixes that by checking if the second operand and fourth operand are
immediate and have the same value.
Reviewed By: david-arm
Differential Revision: https://reviews.llvm.org/D147617
I noticed, when examining the generated Asm Matcher table, that some of
these custom immediate operands are missing, and so we are not parsing
some hint aliases into the correct MCInst.
Where this becomes apparent is when you parse e.g. `hint #7` into an
MCInst - without these cases, it becomes the MCInst `(HINT 17)`, which
will always be printed as `hint #17`. With these cases, it becomes the
MCInst `XPACLRI`, which will be printed as `xpaclri` with pauth, or
`hint #17` without, matching how `xpaclri` is parsed.
We only handle some specific hint aliases in this manner, usually where
these hints have specific effects that need to be modelled for accurate
code-generation. Otherwise, we just use the normal `InstAlias` system
to have the aliases parsed into a `(HINT N)` MCInst.
Differential Revision: https://reviews.llvm.org/D146630
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
Removes the forwarding header `llvm/Support/AArch64TargetParser.h`.
I am proposing to do this for all the forwarding headers left after
rGf09cf34d00625e57dea5317a3ac0412c07292148 - for each header:
- Update all relevant in-tree includes
- Remove the forwarding Header
Differential Revision: https://reviews.llvm.org/D140999
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
