Stabilize ppc inline assembly

[pmur]

This stabilizes inline assembly for PowerPC and PowerPC64.

Corresponding reference PR: rust-lang/reference#2056

---

From the requirements of stabilization mentioned in #93335

Each architecture needs to be reviewed before stabilization:

• It must have clobber_abi.

Done in #146949.

• It must be possible to clobber every register that is normally clobbered by a function call.

Done in #131341

Similarly, preserves_flags is also implemented by this PR. Likewise, there is a non-code change to preserve_flags expectations that floating point and vector status and sticky bits are preserved. The reference manual update has more details.

• Generally review that the exposed register classes make sense.

The followings can be used as input/output:

• reg (r0, r[3-12], r[14-r28]): Any usable general-purpose register
• reg_nonzero (r[3-12], r[14-r28]): General-purpose registers, but excludes r0. This is needed for instructions which define r0 to be the value 0, such as register + immediate memory operations.
• reg/reg_nonzero r29 on PowerPC64 targets.
• freg (f[0-31]): 64 bit floating pointer registers

The following are clobber-only:

• ctr, lr, xer: commonly clobbered special-purpose registers used in inline asm
• cr (cr[0-7], cr): the condition register fields, or the entire condition register.
• vreg (v[0-31]): altivec/vmx register
• vsreg (vs[0-63]): vector-scalar register
• spe_acc: SPE accumulator, only available for PowerPC SPE targets.

The vreg and vsreg registers technically accept #[repr(simd)] types, but require the experimental altivec or vsx target features to be enabled. That work seems to be tracked here, #42743.

The following cannot be used as operands for inline asm:

• r2: the TOC pointer, required for most PIC code.
• r13: the TLS pointer
• r[29]: Reserved for internal usage by LLVM on PowerPC
• r[30]: Reserved for internal usage by LLVM on PowerPC and PowerPC64
• r31: the frame pointer
• vrsave: this is effectively an unused special-purpose register.

The preserves_flags behavior is updated with the following behavior (Note, this is not enforceable today due to LLVM restrictions):

• All status and sticky bits of fpscr, spefscr, and vscr are preserved.

The following registers are unavailable:

• mma[0-7]: These are new "registers" available on Power10, they are 512b registers which overlay 4x vsx registers. If needed, users can mark such clobbers as vsN4, vsN4+1,...,vsN*4+3.
• ap: This is actually a pseudo-register in gcc/llvm.
• mq: This register is only available on Power1 and Power2, and is not supported by llvm.

---

cc @taiki-e
r? @Amanieu
@rustbot label +A-inline-assembly

[Amanieu]

The vreg and vsreg registers technically accept #[repr(simd)] types, but require the experimental altivec or vsx target features to be enabled. That work seems to be tracked here, #42743.

These also accept f32 and f64 (as per the docs in rust-lang/reference#2056). Even though the target features are unstable, these are still usable on targets where these features are enabled by default. Passing SIMD vectors will remain implicitly unstable as long as the relevant stdarch bits are unstable.

• r[29-30]: Reserved for internal usage by LLVM

r29 is only reserved on ppc32. We could allow r29 for powerpc64 only.

• fpscr: it is not modelled by gcc or llvm.
• vscr: clang/gcc accept this as a clobber, but do not actually save/restore it.

It would be good to document these as being controlled by preserves_flags like we do in RISC-V. That way when LLVM eventually adds support for modelling these then code will continue to properly handle them.

[folkertdev]

Passing SIMD vectors will remain implicitly unstable as long as the relevant stdarch bits are unstable.

Specifically that would require a PR like #145656 for s390x, which stabilizes the target features (and presumably also the is_powerpc_feature_detected macro).

I'd assume that with this PR merged, stabilizing the vsx and altivec target features at least would be straightforward if there is appetite. If so, it's probably a good idea to ensure (via tests) that the interaction between vector types and asm works as expected.

[taiki-e]

@pmur

• vscr: clang/gcc accept this as a clobber, but do not actually save/restore it.

However, I guess LLVM/GCC could potentially generate code that relies on the VSCR fields being the same before and after inline assembly, when it is not marked as clobbered.

• spe_acc, spefscr: These are available exclusively on the SPE target (the e500, not cell). I am not sure how these are actually used. I think they can be added later if needed.

IIRC, these are used to store the results of SPE-specific instructions.

That said, since all SPE targets are tier 3, it might be fine to ignore them and proceed with stabilization.

---

@folkertdev

Passing SIMD vectors will remain implicitly unstable as long as the relevant stdarch bits are unstable.

Specifically that would require a PR like #145656 for s390x, which stabilizes the target features (and presumably also the is_powerpc_feature_detected macro).

AFAIK, when passing values to inline assembly, the required target features themselves do not need to be stable (since #114467).

Btw, s390x is a bit special in that passing values to vector registers in inline assembly requires a separate unstable feature: #133416 (This is due to vector ABI support being added after the inline assembly stabilization.)

[pmur]

@taiki-e

• vscr: clang/gcc accept this as a clobber, but do not actually save/restore it.

However, I guess LLVM/GCC could potentially generate code that relies on the VSCR fields being the same before and after inline assembly, when it is not marked as clobbered.

Yes, that would make it even more difficult to correctly mark this a clobber. Making it unusable avoids the question of whether codegen will actually preserve it.

@Amanieu

• fpscr: it is not modelled by gcc or llvm.
• vscr: clang/gcc accept this as a clobber, but do not actually save/restore it.

It would be good to document these as being controlled by preserves_flags like we do in RISC-V. That way when LLVM eventually adds support for modelling these then code will continue to properly handle them.

I think the consensus is not to preserve any flags. Notably, XER is partially modeled, but we choose to ignore it. It depends on if and how LLVM/GCC would choose to expose it.

[pmur]

@Amanieu

r29 is only reserved on ppc32. We could allow r29 for powerpc64 only.

Yes, that seems reasonable. See #148492.

In general, is there any issue against relaxing restrictions post stabilization? Particularly, if we add FPSCR/VSCR preservation requirements for preserves_flags which we cannot enforce today.

For FPSCR, are there active plans to support it in LLVM?

[Amanieu]

I think the consensus is not to preserve any flags. Notably, XER is partially modeled, but we choose to ignore it. It depends on if and how LLVM/GCC would choose to expose it.

At the very least we need to ensure that clobber_abi correctly treats these as clobbered at the LLVM level, otherwise this will result in incorrect code if someone attempts to perform a function call which does clobber these. FPSCR and VSCR are fine to ignore for now since LLVM doesn't model the former and treats the latter as volatile (it's not tracked across instructions, only within a single LLVM pseudo-instruction).

This matches the behavior of fcsr and vxsat on RISC-V. We documented those as managed by preserve_flags in case LLVM does gain support for modeling them in the future so that we can then emit correct clobbers depending on what the asm author intended.

This should only be a documentation change, nothing needs to be done in the code.

• spe_acc, spefscr: These are available exclusively on the SPE target (the e500, not cell). I am not sure how these are actually used. I think they can be added later if needed.

• mma[0-7]: These are new "registers" available on Power10, they are 512b registers which overlay 4x vsx registers. They could be added if needed, however their usage is very specialized.

• ap, mq: I don't think these registers exist on any usable power target supported by gcc/llvm

Even if we don't expose these directly as clobbers, we still need to ensure that clobber_abi properly marks them as clobbered if the default function call ABI treats these as volatile.

[pmur]

I've updated the reference patch require preserving all status and sticky bits of the *scr registers, mq, and acc. Likewise, ap appears to be a pseudo-register for the Argument Register. It's usage isn't described in any ABI's I can find.

[Amanieu]

I spent some time working on PowerPC support in Amanieu/corosensei#61, which makes heavy use of inline asm. Based on the experience, I think we actually need additional guarantees when executing asm without nostack. While the normal asm rules allow writing to addresses below the stack pointer in this case, the function call sequence on PowerPC additionally requires access to several fields on the caller's stack frame, notably the LR save slot at SP + 16. This works because SP is always guaranteed to point to a valid stack frame with the CR, TOC, LR and back-chain fields at fixed offsets from the stack pointer. We should document this additional guarantee in the reference.

I also spent some time thinking about the extra register classes that we put into preserve_flags. It's fine to have spefscr in there but the acc register would be better treated as a normal register class. While we still need acc in the compiler for clobber_abi, it shouldn't be stabilized and should be placed under asm_experimental_reg.

Finally I think mq can just be removed since that's not a target we will ever support.

[pmur]

This works because SP is always guaranteed to point to a valid stack frame with the CR, TOC, LR and back-chain fields at fixed offsets from the stack pointer. We should document this additional guarantee in the reference.

Ok. I'll add a section. We should allow ABI sanctioned modifications to the caller's frame. The parameter storage space is another place which could come up in the future.

Adding acc makes sense, though it is not accepted by gcc. An attempt here, #149608. Glancing through the SPE manual, it seems it only supports 64b and 2x32b types. If there is no support beyond clobbering, is it worth mentioning in asm_experimental_regs?

[Amanieu]

The only reason for putting it under asm_experimental_regs is so that we don't stabilize it along with the rest of PPC asm.

[Amanieu]

I think this is ready for stabilization. @pmur could you write up a stabilization report and then nominate this for the lang team?

[bors]

☔ The latest upstream changes (presumably #149632) made this pull request unmergeable. Please resolve the merge conflicts.

[Amanieu]

You also need to specifically emit an error on spe_acc when tcx().features().asm_experimental_reg() is false.

[pmur]

You also need to specifically emit an error on spe_acc when tcx().features().asm_experimental_reg() is false.

If checking is done similiar to other ppc register restrictions, it will error if clobber_abi is used. Is there reason not to stabilize spe_acc as a clobber-only register? asm_experimental_reg checks would be needed if support grows beyond clobbering. Aside, looking at llvm source, I don't think it models the SPE accumulator.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[pmur]

I think including spe_acc as a clobber-only register restricted to SPE targets should be OK to stabilize?

As for a stabiization report, I copied the format of the s390 stabilization PR. The language feature stabilization template in the manual doesn't seem like a good fit here.

[tmandry]

@rfcbot reviewed

[rust-rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

[pmur]

@Amanieu are there any issues left to resolve here?

[Amanieu]

@bors r+

[rust-bors]

📌 Commit 31ce232 has been approved by Amanieu

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 1000. This pull request will be tested once the tree is reopened.

[rust-bors]

⌛ Testing commit 31ce232 with merge e8cccfb...

Workflow: https://github.com/rust-lang/rust/actions/runs/21381154869

[Zalathar]

@bors yield (to enclosing rollup)

[rust-bors]

Auto build cancelled. Cancelled workflows:

• https://github.com/rust-lang/rust/actions/runs/21381154869

The next pull request likely to be tested is #151716.