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:

• 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, GPU and BPF.)

• Arm64EC
  • clobber_abi
    • clobber_abi is implemented but broken: https://godbolt.org/z/r3PTrGz5r
    • Open PR: Fix clobber_abi and disallow SVE-related registers in Arm64EC inline assembly #131332
  • preserves_flags
  • Disallow SVE-related registers (Fix clobber_abi and disallow SVE-related registers in Arm64EC inline assembly #131332 (comment))
    • Open PR: Fix clobber_abi and disallow SVE-related registers in Arm64EC inline assembly #131332
• Nvptx64
  • clobber_abi
  • preserves_flags?
• Hexagon
  • p* register (clobber-only) should be supported (needed for writing code with branching)
  • clobber_abi
    • Refs: "7 Register usage across calls" in Qualcomm Hexagon™ Application Binary Interface User Guide
  • preserves_flags?
• Mips, Mips64
  • clobber_abi
    • Refs(MIPS32): "Function Calling Sequence" in System V Application Binary Interface MIPS RISC Processor Supplement, 3rd Edition
  • preserves_flags?
• PowerPC, PowerPC64
  • v* register (at least as clobber-only) should be supported (needed for clobber_abi on PowerPC64)
    • Open PRs: Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly #131341, Support #[repr(simd)] types in input/output of PowerPC inline assembly #131551
  • clobber_abi
    • Refs(PPC32 SysV): "Function Calling Sequence" in System V Application Binary Interface PowerPC Processor Supplement
    • 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/open PRs: Add asm clobbers for PPC / PPC64 #111335, Add support for ppc64le clobber_abi #124279, Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly #131341
  • preserves_flags
    • (IIUC) xer and cr* supported as clobber-only registers correspond to (some of) this.
    • FPSCR and VSCR?
• SpirV: unsupported in LLVM/GCC backend
• Wasm32, Wasm64
  • clobber_abi
  • preserves_flags?
• Bpf
  • clobber_abi
  • preserves_flags?
• AVR
  • clobber_abi
    • Refs: https://gcc.gnu.org/wiki/avr-gcc#Call-Used_Registers
    • Open PR: Support clobber_abi in AVR inline assembly #131323
  • 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: 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
  • clobber_abi
    • Refs: https://m680x0.github.io/doc/abi.html
  • 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
  • clobber_abi
    • Refs(v2): "2.2.1 Register Assignments" in C-SKY V2 CPU Applications Binary Interface Standards Manual
  • 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",
    	};

• Xtensa: unsupported in rust-lang/rust (supported in esp-rs fork)

---

FYI:

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