Tracking Issue for asm_experimental_arch

[Amanieu]

The feature gate for the issue is #![feature(asm_experimental_arch)].

Summary

This feature tracks asm! and global_asm! support for the following architectures:

• Arm64ec: Stabilize Arm64EC inline assembly #131781
• NVPTX
• PowerPC
• Hexagon
• MIPS32r2 and MIPS64r2
• wasm32
• BPF
• SPIR-V
• AVR
• MSP430
• s390x: Stabilize s390x inline assembly #131258

Status

Each architecture needs to be reviewed before stabilization:

• It must have clobber_abi.
• It must be possible to clobber every register that is normally clobbered by a function call.
• Generally review that the exposed register classes make sense.

[solomatov]

Is there any chance that wasm32 assembly support will be stabilized any time soon? Are there any tasks where contributions might speed this up?

[AtomicGamer9523]

Is there any news about AVR ? If not, where and how can I contribute to this?

[tgross35]

The top post mentions the following:

Each architecture needs to be reviewed before stabilization:
* It must have clobber_abi.
* It must be possible to clobber every register that is normally clobbered by a function call.
* Generally review that the exposed register classes make sense.

Anyone can post a stabilization (or status) report answering the above, probably with examples/tests, and that would be a good place for any platform to start. It would also be good to make sure there aren't any open LLVM issues, and mention it there.

The bar for enabling AVR should be pretty low since it is tier 3. I am not a decision maker here but I think any of the tier 3 targets could probably be stabilized with just the report and some real-world usage backing it up.

I'm not sure what exactly would be needed for the tier 2 and above targets, e.g. WASM as requested by @solomatov. Having a better picture of LLVM support is more important. @alexcrichton maybe you have an idea about the WASM picture here, or know who would?

[tgross35]

Cc @ecnelises with the above in case you are interested in moving ppc assembly forward, based on linked issues it seems like there may be some ecosystem use cases.

[alexcrichton]

Ah I don't know very much about inline assembly for the wasm target. I believe it works enough to do "some things" but that's the extent of my knowledge, and I wouldn't be prepared to assist with or myself propose stabilization. I also don't know who might know more about the wasm side of things other than "generally LLVM folks doing wasm things may know more", which I realize is unfortunately not very specific or actionable...

[tgross35]

@AtomicGamer9523 #131258 is an example of stabilizing assembly for a target that is behind this feature. You could probably put up a similar PR for AVR.

[taiki-e]

In my understanding, here is the status on each architecture other than s390x (which already has stabilization PR):
(Disclaimer: I'm not an expert of any of these. In particular, I know almost nothing about asm for WASM, GPUs, and BPF.)

• Arm64EC: stabilization PR: Stabilize Arm64EC inline assembly #131781
  • clobber_abi
    • clobber_abi is implemented but broken: https://godbolt.org/z/r3PTrGz5r
    • Done in Fix clobber_abi and disallow SVE-related registers in Arm64EC inline assembly #131332
  • preserves_flags (same as AArch64)
  • Disallow SVE-related registers (Fix clobber_abi and disallow SVE-related registers in Arm64EC inline assembly #131332 (comment))
    • Done in Fix clobber_abi and disallow SVE-related registers in Arm64EC inline assembly #131332
• Nvptx64
  • clobber_abi
    • it seems that this architecture has no named registers
      

      rust/compiler/rustc_target/src/asm/nvptx.rs

      Lines 47 to 49 in 83ab648

      	// Registers in PTX are declared in the assembly.
      	// There are no predefined registers that one can use.
      	Nvptx NvptxInlineAsmReg NvptxInlineAsmRegClass {}

    • information needed for clobber_abi is private?? https://forums.developer.nvidia.com/t/the-calling-process-of-device-function/287822/4
  • preserves_flags?
• Hexagon
  • Predicate (p*) register (clobber-only) should be supported (needed for clobber_abi and writing code with branching))
    • Clang: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/clang/lib/Basic/Targets/Hexagon.cpp#L161
    • LLVM: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Hexagon/HexagonRegisterInfo.td#L155
    • ISA: https://docs.qualcomm.com/bundle/publicresource/80-N2040-53_REV_AB_Qualcomm_Hexagon_V73_Programmers_Reference_Manual.pdf#page=30
    • Done in Support predicate registers (clobber-only) in Hexagon inline assembly #133452
  • clobber_abi
    • Refs:
      • "7 Register usage across calls" in Qualcomm Hexagon™ Application Binary Interface User Guide
      • LLVM https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Hexagon/HexagonRegisterInfo.cpp#L67
  • preserves_flags?
    • (IIUC) Predicate registers correspond to this.
• Mips, Mips64
  • clobber_abi
    • Refs(MIPS32): "Function Calling Sequence" in System V Application Binary Interface MIPS RISC Processor Supplement, 3rd Edition
    • LLVM https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Mips/MipsRegisterInfo.td#L283
  • preserves_flags
    • Floating Point condition code
      • LLVM https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Mips/MipsRegisterInfo.td#L201-L203
• PowerPC, PowerPC64
  • v* register (at least as clobber-only) should be supported (needed for clobber_abi on PowerPC64)
    • Done in Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly #131341
    • Support input/output in vector registers of PowerPC inline assembly #131551
  • clobber_abi
    • Refs(PPC32 SysV): "3.2. Function Calling Sequence" in Power Architecture 32-bit Application Binary Interface Supplement 1.0 - Linux & Embedded
    • Refs(PPC64 ELFv1): "3.2. Function Calling Sequence" in 64-bit PowerPC ELF Application Binary Interface Supplement
    • Refs(PPC64 ELFv2): "2.2 Function Calling Sequence" in 64-Bit ELF V2 ABI Specification
    • Refs(AIX): Register usage and conventions, Special registers in the PowerPC®, AIX vector programming
    • Previous attempts: Add asm clobbers for PPC / PPC64 #111335, Add support for ppc64le clobber_abi #124279
    • Done in Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly #131341
  • FIXME on 32-bit ABI: Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly #131341 (comment)
  • spe_acc register (volatile) in PPC32 SPE ABI
    • Clang https://github.com/llvm/llvm-project/blob/590f451b60d434b26c634a07125fb05baf461fa0/clang/lib/Basic/Targets/PPC.cpp#L842
    • GCC (note: SPE support has been removed in GCC 9) https://github.com/gcc-mirror/gcc/blob/7d5175e1e494e0a514019347723b7afc34a459db/gcc/config/rs6000/rs6000.c#L769
  • preserves_flags
    • (IIUC) xer and cr* supported as clobber-only registers correspond to (some of) this.
    • FPSCR/VSCR/SPEFSCR?
      • https://llvm.godbolt.org/z/fbex9hxEz
• SpirV: unsupported in LLVM/GCC backend
  • clobber_abi
    • it seems that this architecture has no named registers
      

      rust/compiler/rustc_target/src/asm/spirv.rs

      Lines 45 to 46 in 83ab648

      	// SPIR-V is SSA-based, it does not have registers.
      	SpirV SpirVInlineAsmReg SpirVInlineAsmRegClass {}

  • preserves_flags?
• Wasm32, Wasm64
  • clobber_abi
    • it seems that this architecture has no named registers
      

      rust/compiler/rustc_target/src/asm/wasm.rs

      Lines 45 to 46 in 83ab648

      	// WebAssembly doesn't have registers.
      	Wasm WasmInlineAsmReg WasmInlineAsmRegClass {}

  • preserves_flags?
• Bpf
  • clobber_abi
    • Refs: https://github.com/torvalds/linux/blob/v6.12/Documentation/bpf/standardization/abi.rst
  • preserves_flags?
• AVR
  • Registers that must be reserved for AVRTiny is not reserved Support clobber_abi in AVR inline assembly #131323 (comment)
  • clobber_abi
    • Refs: https://gcc.gnu.org/wiki/avr-gcc#Call-Used_Registers
    • AVR
      • Done in: Support clobber_abi in AVR inline assembly #131323
    • AVRTiny a different convention Support clobber_abi in AVR inline assembly #131323 (comment)
  • preserves_flags
    • Docs simply says "The status register SREG", but (IIUC) I (Global Interrupt Enable) bit of it should not actually be considered as a target of this option. (the same as MSP430 case)
  • experimental in LLVM? (I'm not sure if this would be a blocker)

    rust/src/bootstrap/src/core/build_steps/llvm.rs

    Lines 339 to 342 in 8f8bee4

    	let llvm_exp_targets = match builder.config.llvm_experimental_targets {
    	Some(ref s) => s,
    	None => "AVR;M68k;CSKY;Xtensa",
    	};

• MSP430
  • clobber_abi
    • Refs: "3.2 Register Conventions" in MSP430 Embedded Application Binary Interface
    • Done in Support clobber_abi in MSP430 inline assembly #131310
  • preserves_flags
    • Docs simply says "The status register r2", but (IIUC) only C, Z, N, and V bits of it are should actually be considered as targets of this option. (previous discussion)
• M68k
  • fp* register (at least as clobber-only) should be supported (needed for clobber_abi)
  • clobber_abi
    • Refs:
      • https://m680x0.github.io/doc/abi.html#calling-convention
      • GCC https://github.com/gcc-mirror/gcc/blob/ab78ee298864b5db8fb81e263fc0d64bfd8f082d/gcc/config/m68k/m68k.h#L358
      • LLVM https://github.com/llvm/llvm-project/blob/60d2feded5c0f55b21d042ee2f35227847d66ee0/llvm/lib/Target/M68k/M68kCallingConv.td
  • preserves_flags
    • ccr
    • (IIUC) fpsr (condition code byte and quotient code byte?) should also be handled in preserves_flags
  • experimental in LLVM? (I'm not sure if this would be a blocker)

    rust/src/bootstrap/src/core/build_steps/llvm.rs

    Lines 339 to 342 in 8f8bee4

    	let llvm_exp_targets = match builder.config.llvm_experimental_targets {
    	Some(ref s) => s,
    	None => "AVR;M68k;CSKY;Xtensa",
    	};

• CSKY
  • no test in tests/assembly/asm
  • clobber_abi
    • Refs(v2):
      • "2.2.1 Register Assignments" in C-SKY V2 CPU Applications Binary Interface Standards Manual
      • LLVM https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/CSKY/CSKYCallingConv.td
  • preserves_flags
    • Condition/carry bit (C) (the lowest bit of PSR)
      • LLVM https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/CSKY/CSKYRegisterInfo.td#L88
  • experimental in LLVM? (I'm not sure if this would be a blocker)

    rust/src/bootstrap/src/core/build_steps/llvm.rs

    Lines 339 to 342 in 8f8bee4

    	let llvm_exp_targets = match builder.config.llvm_experimental_targets {
    	Some(ref s) => s,
    	None => "AVR;M68k;CSKY;Xtensa",
    	};

• Sparc, Sparc64:
  • Initial implementation
    • Open PR Basic inline assembly support for SPARC and SPARC64 #132472
  • floating-point register support (needed for clobber_abi)
  • resolve FIXMEs
    • (SPARC-V8+ specific)

      rust/compiler/rustc_target/src/asm/sparc.rs

      Lines 46 to 48 in 241f82a

      	// FIXME: i64 is ok for g*/o* registers on SPARC-V8+ ("h" constraint in GCC),
      	// but not yet supported in LLVM.
      	// v8plus: I64;

    • (SPARC-V8+ specific)

      rust/compiler/rustc_target/src/asm/sparc.rs

      Lines 67 to 72 in 241f82a

      	// FIXME: Section 2.1.5 "Function Registers with Unassigned Roles" of the V8+ Technical
      	// Specification says "%g5; no longer reserved for system software" [1], but LLVM always
      	// reserves it on SPARC32 [2].
      	// [1]: https://temlib.org/pub/SparcStation/Standards/V8plus.pdf
      	// [2]: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/SparcRegisterInfo.cpp#L64-L66
      	Err("g5 is reserved for system on SPARC32")

    • (all)

      rust/compiler/rustc_target/src/asm/sparc.rs

      Lines 80 to 84 in 241f82a

      	// FIXME:
      	// - LLVM has reserve-{g,o,l,i}N feature to reserve each general-purpose registers.
      	// - g2-g4 are reserved for application (optional in both LLVM and GCC, and GCC has -mno-app-regs option to reserve them).
      	// There are currently no builtin targets that use them, but in the future they may need to
      	// be supported via options similar to AArch64's -Z fixed-x18.

    • (all)

      rust/compiler/rustc_target/src/asm/sparc.rs

      Lines 113 to 115 in 241f82a

      	// FIXME: %g1 is volatile in ABI, but used internally by LLVM.
      	// https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/SparcRegisterInfo.cpp#L55-L56
      	// > FIXME: G1 reserved for now for large imm generation by frame code.

  • clobber_abi
    • Refs: see "Refs:" in Basic inline assembly support for SPARC and SPARC64 #132472
  • preserves_flags
    • Open PR Basic inline assembly support for SPARC and SPARC64 #132472
• Xtensa:
  • unsupported in rust-lang/rust (supported in esp-rs fork and IIUC upstreaming this to rust-lang/rust needs LLVM 20 (llvm/llvm-project@dc2d0d5))
  • clobber_abi
  • preserves_flags?
    • (IIUC) Boolean registers correspond to this.
  • experimental in LLVM (I'm not sure if this would be a blocker)

    rust/src/bootstrap/src/core/build_steps/llvm.rs

    Lines 339 to 342 in 8f8bee4

    	let llvm_exp_targets = match builder.config.llvm_experimental_targets {
    	Some(ref s) => s,
    	None => "AVR;M68k;CSKY;Xtensa",
    	};

---

FYI:

• clobber_abi related code is here.
• preserves_flags related code (LLVM) is here.
• See getReservedRegs in LLVM repo for registers reserved by LLVM.