Inline Asm Constraints and Modifiers - RVC, Raw Encodings, Pairs

[lenary]

We have customers with usecases that want more kinds of register constraints and modifiers. This change proposes support for these constraints and modifiers, and their names.

Broadly, these are intended to make it easier for users who want to manually assemble instructions inside inline assembly blocks, either using the existing instruction formats, or using the raw form of the .insn directive. This makes it easier for hardware designers to experiment on new ISA extensions, and makes it easier to support the use of proprietary extensions with unmodified open-source toolchains.

There are three groups of additions here:

• Constraints for RVC-compatible registers. These use the c prefix on an existing register constraint, so cr gives a GPR between x8-x15, and cf does the same for an FPR between f8-f15.

  I'm not aware of compressed vector instructions, but we could add cvr, cvd and cvm in the future if the core architecture ends up having the concept of a vector register with an RVC encoding.

• A modifier, N, to print the raw encoding of a register. This is used when using .insn <length>, <encoding>, where the user wants to pass a value to the instruction in a known register, but where the instruction doesn't follow the existing instruction formats, so the assembly parser is not expecting a register name, just a raw integer.

• Constraints for even-odd pairs of general-purpose registers. These use the R constraint.

  While the concept of even-odd register pairs is reasonably "new", there are places in the architecture where these already exist - the doubleword/quad CAS in Zacas, and they are also present in the Zilsd specification.

---

There's also a commit which fixes a header for the Assembly Constraints table.

[lenary]

I have an LLVM implementation of the c* constraints and the N modifier here https://github.com/llvm/llvm-project/pull/112561 which has been approved.

I am still working on the implementation of the Pr constraint.

[lenary]

There was a question on #39 about whether the paired constraint means "an even GPR", or a "even-odd GPR pair", as both would likely print exactly the same as the even subregister.

This matters for liveness analysis as, if Pr meant "an even GPR", the odd GPR in the pair might be allocated to a different input/output for the inline assembly block, which would conflict with the use of the even/odd value for a pair.

So, to be clear, Pr means "treat this as an even-odd GPR pair for liveness" and "print this as the even subregister", so if the compiler choses a0/a1, then a0 is printed, but a1 will also be defined/used by the inline assembly block.

[lenary]

I just opened https://github.com/llvm/llvm-project/pull/112983 which implements the Pr constraint.

[lenary]

Gentle Ping

Is there anything missing from the textual additions that is needed to clarify the proposal?

How are people feeling about this proposal?

[kito-cheng]

The proposal look good, let me make sure it's implementable on GCC side before we moving forward...:P

[cmuellner]

Kito just mentioned in the Toolchain SIG that he has a PoC implementation of this for LLVM and GCC.