Remove useless function multiversioning features

[andrewcarlotti]

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

---

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 X those which apply)

• [ ] If an issue reporting the bug exists, I have mentioned it in the PR (do not bother creating the issue if all you want to do is fixing the bug yourself).
• [ ] I have added/updated the SPDX-FileCopyrightText lines on top of 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 use commas to separate gaps, as in 2018-2020, 2022).
• [ ] I have updated the Copyright section of the sources of the specification 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.
• [ ] I have run the CI scripts (if applicable, as they might be 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.
• [x] I have added an item that describes the changes I have 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.
• [ ] When modifying content and/or its rendering, I have checked the correctness of the result in the PDF output (please refer to the instructions on how to build the PDFs locally).
• [x] The variable draftversion is set to true in the YAML header of the sources of the specifications I have modified.
• [ ] Please DO NOT add my GitHub profile to the list of contributors in the README page of the project.

[labrinea]

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".

[labrinea]

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.

[DanielKristofKiss]

"Features that indicate support for hint instructions: these can be dropped, since the instructions can be used unconditionally." but still the functionality may matters. FMV could be used for other stuff beside codegen.

[andrewcarlotti]

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".

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.

[Wilco1]

Can we progress this? It seems there is agreement on most of these, so just keep FEAT_BTI.

[labrinea]

Ping @DanielKristofKiss @rsandifo-arm

[DanielKristofKiss]

@labrinea I think we need new version of this PR to reflect above comments and also has merge conflicts.

[vhscampos]

Hi all, can you please confirm if this patch has already been approved? If it's just a matter of resolving merge conflicts, I can do it

[labrinea]

Hey Victor. No, it hasn't been approved. It is still work in progress. Cheers.

[jroelofs]

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.

In the case of bti this conflates the status of the flag with the test for the presence of the ISA feature. You're right that FMV isn't appropriate for a status check, but it is useful for the ISA feature presence check, which for dit you need around your msr dit, x0's. I'm not sure about memtag4 and/or ebf16.