This is an archive of the discontinued LLVM Phabricator instance.

[ARM] Permit VGETLNi32 and VSETLNi32 without mnemonic suffix.
ClosedPublic

Authored by simon_tatham on Aug 2 2023, 2:33 AM.

Details

Summary

These instructions transfer 32 bits of data between an integer
register and half of a d-register. Currently LLVM accepts them only
with the syntax vmov.32 r0, d0[0] or vmov.32 d0[0], r0. But the
ARMARM says that the .32 suffix on the mnemonic should be optional.

Added a pair of NEONInstAlias to accept the bare vmov version, and
checked that the result is the same as with .32.

This only adds new syntax accepted in assembly. The existing explicit
version is still used when disassembling these instructions.

Diff Detail

Event Timeline

simon_tatham created this revision.Aug 2 2023, 2:33 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 2 2023, 2:33 AM
simon_tatham requested review of this revision.Aug 2 2023, 2:33 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 2 2023, 2:33 AM
dmgreen accepted this revision.Aug 2 2023, 3:20 AM

LGTM

This revision is now accepted and ready to land.Aug 2 2023, 3:20 AM

Correction: using NEONInstAlias was a mistake because it meant the
aliases had stricter requirements than the instructions they map to.
The revised version of the patch gives each alias the same
requirements as its base instruction. For example, these aliases are
now accepted in thumbv7m as well as armv8a.

I'm a bit worried to find that those requirements are different,
though. VSETLNi32 simply requires HasVFP2, whereas VGETLNi32
requires both HasFPRegs and HasFastVGETLNi32. I would have thought
that the matching get and set operations ought to be enabled by the
same feature! And surely HasFastVGETLNi32 only ought to be
conditionalizing the selection of VGETLNi32 during compilation,
and shouldn't also make it illegal to write by hand in assembler.

But those are probably things to fix in a separate patch.

Further correction: in this version I had to explicitly set EmitPriority or several tests failed.

For example, these aliases are now accepted in thumbv7m as well as armv8a.

Ah I see. The v8.1-m reference I had looked at didn't have the same optional instruction suffix. IIRC we don't use VGETLNi32 for MVE, it goes via MVE_VMOV_from_lane_32 instead, and the D reg variant is an alias of the Q reg version (and doesn't mark the size as optional in the same way). They do look like they were there in v7m though.

Even better idea: instead of repeating the list of predicates in each InstAlias, I can just import them by pulling out the Predicates field of the instruction record that each one expands to. Then if we do fix the VGETLNi32/VSETLNi32 mismatch later, the aliases will automatically pick up the same change without anyone having to remember to fix it in two places.

(I don't know why InstAlias doesn't do this automatically, now I think about it!)

dmgreen accepted this revision.Aug 3 2023, 4:38 AM

I didn't even know that was possible. It still sounds good to me.

This revision was landed with ongoing or failed builds.Aug 3 2023, 5:21 AM
This revision was automatically updated to reflect the committed changes.