This is an archive of the discontinued LLVM Phabricator instance.

[AArch64] Add new v9.4-A PM pstate system register
ClosedPublic

Authored by pratlucas on Dec 13 2022, 2:32 AM.

Details

Summary

This adds support for the new PM pstate system register introduced by
the v9.4-A Exception-based Event Profiling extension (FEAT_EBEP).

The new PM pstate register takes a 1-bit immediate and requires
different values to be specified for the higher bits of the Crm field.
To enable that, this patch creates an explicit separation between the
pstate system registers that take 4-bit and 1-bit immediate operands,
allowing each entry to specify the value for the 3 high bits of Crm.

This also updates other pstate registers to correctly accept 4-bit
immediates, matching their decoding specification from the Arm ARM.
These include: PAN, UAO, DIT and SSBS.

More information about this extension and the new register can be found
at:

Contributors:

  • Lucas Prates
  • Sam Elliott

Diff Detail

Event Timeline

pratlucas created this revision.Dec 13 2022, 2:32 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 13 2022, 2:32 AM
pratlucas requested review of this revision.Dec 13 2022, 2:32 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 13 2022, 2:32 AM

We likely have to release-note this change, as we are now are:

  • not going to error for assembly where upper bits which do nothing are set in the immediate
  • may codegen e.g. __arm_wsr64("uao", 2) to the assembly msr uao, 2 which is not accepted by binutils.

Both of these are intentional changes, though.

Also a nit about testing.

llvm/lib/Target/AArch64/AArch64InstrFormats.td
1793

Do we have decoding tests for the case where you fallback from MSRpstateImm0_15 to MSRpstateImm0_1 to MSRI? This would presumably be a test where we use an unallocated MSR (imm) encoding?

Indeed. I'll add an entry to the release notes to capture that.

llvm/lib/Target/AArch64/AArch64InstrFormats.td
1793

The fallback applies every time the decoder method fails due to the lack of the required feature for a particular pstate register.
This is currently covered by the negative tests for PAN, UAO, DIT, SSBS, and TCO.

pratlucas marked an inline comment as not done.Dec 13 2022, 6:25 AM
pratlucas added inline comments.
llvm/lib/Target/AArch64/AArch64InstrFormats.td
1793

On a deeper look, this existing behaviour doesn't look like the best approach to handle those situations. MSRI ends up decoding the instruction using the register form of the msr instruction, generating a somewhat meaningless result.
I'll have a look into an alternative for that, but given that's existing behaviour the change may go into a separate patch.

lenary added inline comments.Dec 14 2022, 5:21 AM
llvm/lib/Target/AArch64/AArch64InstrFormats.td
1793

I'll have a look into an alternative for that, but given that's existing behaviour the change may go into a separate patch.

As long as we can parse whatever we produce, I think it should be ok. Maybe worth checking what binutils prints in these cases?

pratlucas marked 2 inline comments as done.Dec 15 2022, 3:20 AM
pratlucas added inline comments.
llvm/lib/Target/AArch64/AArch64InstrFormats.td
1793

Yes, I've double checked the results we produce and they are assembled back into the correct instruction.
Binutils doesn't check for which features are enabled and just disassembles the feature-specific register name. For unallocated/reserved encodings, binutils behaves the same way as llvm, so I think we are ok indeed.

pratlucas edited the summary of this revision. (Show Details)Dec 15 2022, 3:35 AM
lenary accepted this revision.Dec 16 2022, 7:32 AM
This revision is now accepted and ready to land.Dec 16 2022, 7:32 AM
This revision was landed with ongoing or failed builds.Dec 19 2022, 7:07 AM
This revision was automatically updated to reflect the committed changes.
pratlucas marked an inline comment as done.