Remove useless function multiversioning features #315
Conversation
Supporting a feature in function multiversioning requires that the rest of the toolchain can support enabling the feature. In GCC/Binutils, this requires either that there is an equivalent feature extension available in the `-march` command line option, or that the feature introduces no new instructions (and therefore does not need to be enabled when passing to the assembler). However, many of the features listed in in the original function multiversioning specification do not meet this criteria. These fall into four categories: 1. Features that were originally linked to a specific architecture version (fcma, jscvt, frintts, flagm2, wfxt, rcpc2): these should get their own flags across the toolchain (and I've already added this support in Binutils). 2. Features that are combined with other features in existing command line options: these should also be merged in the function multiversioning specification. 3. Features that indicate support for hint instructions: these can be dropped, since the instructions can be used unconditionally. 4. Features that enable existing instruction behaviour to be changed when a system register flag is set: the function multiversioning resolvers don't check for runtime enablement of the control flags, so this isn't a suitable way of exploiting the behaviour enabled by those flags. 5. Features that can also be expressed as a combination of two other features. We therefore remove support for the following features from the specification: - sha1 (2): included within +sha2 - pmull (2): included within +aes - dit (4) - dgh (3) - ebf16 (4) - sve-bf16 (5) - sve-ebf16 (4) - sve-i8mm (5) - sve2-pmull128 (2): included within +sve2-aes - memtag2 (2): included within +memtag - memtag3 (4) - ssbs2 (2): included within +ssbs - bti (3) - ls64_v, ls64_accdata (2): included within +ls64
andrewcarlotti
force-pushed
the
fmv-feature-removal
branch
from
dec82a1
to
1d0e035
Compare
It currently isn't possible to support function multiversioning features
properly in GCC without also enabling the extension in the command line
options (with the exception of features such as "rpres" that do not
require assembler support). We therefore remove unsupported features
from GCC's list of FMV features.
Some of these features ("fcma", "jscvt", "frintts", "flagm2", "wfxt",
"rcpc2", and perhaps "dpb" and "dpb2") will be added back in the future
once support for the command line option has been added.
The rest of the removed features I have proposed removing from the ACLE
specification as well, since it doesn't seem worthwhile to include support
for them; see the ACLE pull request for more detailed justification:
ARM-software/acle#315
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def:
Remove "flagm2", "sha1", "pmull", "dit", "dpb", "dpb2", "jscvt",
"fcma", "rcpc2", "frintts", "dgh", "ebf16", "sve-bf16",
"sve-ebf16", "sve-i8mm", "sve2-pmull128", "memtag3", "bti" and
"wfxt" entries.
Some architecture features have been combined under a single command line flag, but have been assigned multiple FMV feature names with the command line flag name enabling only a subset of these features in the FMV specification. I've proposed reallocating names in the FMV specification to match the command line flags [1], but for GCC 14 we'll just remove them from the FMV feature list. [1] ARM-software/acle#315 gcc/ChangeLog: * config/aarch64/aarch64-option-extensions.def: Remove "memtag", "memtag2", "ssbs", "ssbs2", "ls64", "ls64_v" and "ls64_accdata" FMV features.
|
All the suggested changes LGTM. Another feature in question that I believe falls in the second category is "ssbs" (included within +ssbs2) and one that falls in the forth category is "rpres". |
Oh I realised ssbs was already on your list, I must have missed it. |
As explained in ARM-software/acle#315 we are deprecating features which aren't adding any value.
As explained in ARM-software/acle#315 we are deprecating features which aren't adding any value. These are: sha1, pmull, dit, dgh, ebf16, sve-bf16, sve-ebf16, sve-i8mm, sve2-pmull128, memtag2, memtag3, ssbs2, bti, ls64_v, ls64_accdata
As explained in ARM-software/acle#315 we are deprecating features which aren't adding any value. These are: sha1, pmull, dit, dgh, ebf16, sve-bf16, sve-ebf16, sve-i8mm, sve2-pmull128, memtag2, memtag3, ssbs2, bti, ls64_v, ls64_accdata
This patch is sorting out inconsistencies in TargetParser regarding: * features without corresponding ArchExtKind * features without (Neg)Feature string * features with incorrect DependentFeatures string Also fixes "fp" which incorrectly implied "neon". This leaves us with "rpres" being the only remaining FMV feature with an incomplete entry. We are are currently reviewing it in ARM-software/acle#315. Having accurate ExtensionInfo entries in TargetParser is the only way of propagating the FMV information from clang to LLVM. If we don't want to rely on that we have to come up with another plan of encoding this information in LLVM-IR. For now we are relying on target-features. The PR llvm#87939 is an example of why we need this.
In ACLE we are deprecating a bunch of FMV features (see ARM-software/acle#315), so in this patch I am removing the corresponding tests.
As explained in ARM-software/acle#315 we are deprecating features which aren't adding any value. These are: sha1, pmull, dit, dgh, ebf16, sve-bf16, sve-ebf16, sve-i8mm, sve2-pmull128, memtag2, memtag3, ssbs2, bti, ls64_v, ls64_accdata
| | 470 | `FEAT_SB` | sb | ```ID_AA64ISAR1_EL1.SB == 0b0001``` | | ||
| | 480 | `FEAT_SPECRES` | predres | ```ID_AA64ISAR1_EL1.SPECRES == 0b0001``` | | ||
| | 490 | `FEAT_SSBS` | ssbs | ```ID_AA64PFR1_EL1.SSBS == 0b0001``` | | ||
| | 500 | `FEAT_SSBS2` | ssbs2 | ```ID_AA64PFR1_EL1.SSBS == 0b0010``` | | ||
| | 510 | `FEAT_BTI` | bti | ```ID_AA64PFR1_EL1.BT == 0b0001``` | |
There was a problem hiding this comment.
Please don't drop BTI it is used to detect the feature and generate different code/functionality based on it.
see: https://chromium-review.googlesource.com/c/chromium/src/+/5453915
There was a problem hiding this comment.
So, as I understand it, that use chromium example is using FMV on a function that converts a PageAccessibilityConfiguration into an integer mask that will be passed to mmap calls. The FMV usage is to determine whether the PROT_BTI and PROT_MTE bits should be set in the mask. The main motivation for switching to FMV in this patch is that caching the feature identification check in the GOT is supposedly more resistant to modification by an attacker global structure.
One thing that's not clear to me is whether the check is necessary at all. It looks like the Linux kernel might ignore just PROT_MTE when the system doesn't support it, so maybe it's safe to always pass PROT_MTE in the bitmask. Perhaps the same is true for PROT_BTI. However, I wouldn't fully trust my limited code reading, so might be mistaken.
It's possible to support BTI without adding new command line options, so I'm not particularly opposed to retaining this feature if it is actually useful. It originally felt like there ought to be a better way to handle this use case, but on further consideration approach seems reasonable (assuming that the kernel requires the PROT_BTI and PROT_MTE bits to be unset).
There was a problem hiding this comment.
|
"Features that indicate support for hint instructions: these can be dropped, since the instructions can be used unconditionally." |
Ah - I hadn't noticed that FEAT_RPRES only applied when FEAT_AFP Alternate Handling is enabled. That probably put it in my fourth category as well, although it's slightly less clear cut than the other cases. |
|
Can we progress this? It seems there is agreement on most of these, so just keep FEAT_BTI. |
Supporting a feature in function multiversioning requires that the rest of the toolchain can support enabling the feature. In GCC/Binutils, this requires either that there is an equivalent feature extension available in the
-marchcommand line option, or that the feature introduces no new instructions (and therefore does not need to be enabled when passing to the assembler). However, many of the features listed in in the original function multiversioning specification do not meet this criteria. These fall into four categories:Features that were originally linked to a specific architecture version (fcma, jscvt, frintts, flagm2, wfxt, rcpc2): these should get their own flags across the toolchain (and I've already added this support in Binutils).
Features that are combined with other features in existing command line options: these should also be merged in the function multiversioning specification.
Features that indicate support for hint instructions: these can be dropped, since the instructions can be used unconditionally.
Features that enable existing instruction behaviour to be changed when a system register flag is set: the function multiversioning resolvers don't check for runtime enablement of the control flags, so this isn't a suitable way of exploiting the behaviour enabled by those flags.
Features that can also be expressed as a combination of two other features.
We therefore remove support for the following features from the specification:
name: Pull request
about: Technical issues, document format problems, bugs in scripts or feature proposal.
Thank you for submitting a pull request!
If this PR is about a bugfix:
Please use the bugfix label and make sure to go through the checklist below.
If this PR is about a proposal:
We are looking forward to evaluate your proposal, and if possible to
make it part of the Arm C Language Extension (ACLE) specifications.
We would like to encourage you reading through the contribution
guidelines, in particular the section on submitting
a proposal.
Please use the proposal label.
As for any pull request, please make sure to go through the below
checklist.
Checklist: (mark with
Xthose which apply)PR (do not bother creating the issue if all you want to do is
fixing the bug yourself).
SPDX-FileCopyrightTextlines on topof any file I have edited. Format is
SPDX-FileCopyrightText: Copyright {year} {entity or name} <{contact informations}>(Please update existing copyright lines if applicable. You can
specify year ranges with hyphen , as in
2017-2019, and usecommas to separate gaps, as in
2018-2020, 2022).Copyrightsection of the sources of thespecification I have edited (this will show up in the text
rendered in the PDF and other output format supported). The
format is the same described in the previous item.
tricky to set up on non-*nix machines). The sequence can be
found in the contribution
guidelines. Don't
worry if you cannot run these scripts on your machine, your
patch will be automatically checked in the Actions of the pull
request.
introduced in this PR in the section Changes for next
release of the section Change Control/Document history
of the document. Create Changes for next release if it does
not exist. Notice that changes that are not modifying the
content and rendering of the specifications (both HTML and PDF)
do not need to be listed.
correctness of the result in the PDF output (please refer to the
instructions on how to build the PDFs
locally).
draftversionis set totruein the YAML headerof the sources of the specifications I have modified.
in the README page of the project.