Tracking Issue for asm_experimental_arch

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

Summary

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

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.

See #93335 (comment) for a detailed todo list.

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

Enable feature(asm_experimental_arch) for tests

Gate out test functions that use probe! on ppc64le and s390x

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

@solomatov

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?

@ecnelises

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.

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...

Rollup merge of rust-lang#130630 - taiki-e:s390x-clobber-abi, r=Amanieu

Unrolled build for rust-lang#130630

@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.

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?

Amdgpu
- Initial implementation
  - Pending in Add inline asm support for amdgpu #149793 (comment)
- clobber_abi?
  - it seems that this architecture has no named registers
    https://github.com/rust-lang/rust/pull/149793/files#diff-dc51024eee547c7fb62f3fbfede955a586f0e217d038e8b6357a1f4721a52510
  - See Add inline asm support for amdgpu #149793 (comment)
- preserves_flags?
Hexagon
- Predicate (p*) register (clobber-only) should be supported (needed for clobber_abi and writing code with branching))
- 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: stabilization PR: Stabilize ppc inline assembly #147996
- 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)
- ctr and lr should be supported as clobber-only registers; done in Support ctr and lr as clobber-only registers in PowerPC inline assembly #146831
- 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
  - Done in Allow PowerPC spe_acc as clobber-only register #149608
- 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
  - See Add vsx register support for ppc inline asm, and implement preserves_flag option #146949 (comment) and Allow vscr to be marked as a clobber in PowerPC inline asm #148663
SpirV:
- 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?
- experimental in LLVM (I'm not sure if this would be a blocker)
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.13/Documentation/bpf/standardization/abi.rst#11registers-and-calling-convention
  - Done in Support clobber_abi in BPF inline assembly #136194
- preserves_flags?
  - IIUC, no flags or registers correspond to this.

AVR

Registers that must be reserved for AVRTiny is not reserved Support clobber_abi in AVR inline assembly #131323 (comment)
- Pending in Support AVRTiny devices in AVR inline assembly #146901
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)
  - Pending in Support AVRTiny devices in AVR inline assembly #146901
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:
preserves_flags
- ccr
- fpsr
  From "1.2.3 Floating-Point Status Register (FPSR)" of M68000 FAMILY Programmer's Reference Manual
  
  The FPSR (see Figure 1-2) contains a floating-point condition code (FPCC) byte, a floatingpoint exception status (EXC) byte, a quotient byte, and a floating-point accrued exception
  (AEXC) byte. The user can read or write to all the bits in the FPSR. Execution of most
  floating-point instructions modifies this register. The reset function or a restore operation of
  the null state clears the FPSR.
- fpiar?
  From "1.2.4 Floating-Point Instruction Address Register (FPIAR)" of M68000 FAMILY Programmer's Reference Manual
  
  The integer unit can be executing instructions while the FPU is simultaneously executing a
  floating-point instruction. Additionally, the FPU can concurrently execute two floating-point
  instructions. Because of this nonsequential instruction execution, the PC value stacked by
  the FPU, in response to a floating-point exception trap, may not point to the offending
  instruction.
  For the subset of the FPU instructions that generate exception traps, the 32-bit FPIAR is
  loaded with the logical address of the instruction before the processor executes it. The
  floating-point exception handler can use this address to locate the floating-point instruction
  that caused an exception. Since the FPU FMOVE to/from the FPCR, FPSR, or FPIAR and
  FMOVEM instructions cannot generate floating- point exceptions, these instructions do not
  modify the FPIAR. A reset or a null-restore operation clears the FPIAR.

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
  - Done in Mark condition/carry bit as clobbered in C-SKY inline assembly #136217

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
- Done in 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
- Done in Basic inline assembly support for SPARC and SPARC64 #132472

Xtensa:

Initial implementation
- 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))
- Pending in asm! support for the Xtensa architecture #147302
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.

Avoid `feature(asm_experimental_arch)` on arches that don't need it.

Avoid `feature(asm_experimental_arch)` on arches that don't need it. (#…

phase-117.1: nros-platform-esp32s3-qemu crate

Rollup merge of rust-lang#160949 - beetrees:f128-inline-asm-sparc, r=…

Unrolled build for #160949 in rollup 161566

Rollup merge of #160949 - beetrees:f128-inline-asm-sparc, r=folkertdev

Rollup merge of rust-lang#160851 - beetrees:f16-inline-asm-mips, r=fo…

Unrolled build for #160851 in rollup 161979

Rollup merge of #160949 - beetrees:f128-inline-asm-sparc, r=folkertdev

Rollup merge of #160851 - beetrees:f16-inline-asm-mips, r=folkertdev

Rollup merge of rust-lang#161667 - beetrees:f16-inline-asm-nvptx, r=f…

Unrolled build for #161667 in rollup 163178

Navigation Menu

Repository navigation

Tracking Issue for asm_experimental_arch #93335

Summary

Status

33 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

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

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

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

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

	// 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")

	// 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.

	// 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.

Tracking Issue for asm_experimental_arch #93335

Description

Summary

Status

Activity

solomatov commented on Aug 11, 2024

matveitolochko commented on Sep 27, 2024

tgross35 commented on Sep 27, 2024

tgross35 commented on Sep 27, 2024

alexcrichton commented on Sep 28, 2024

tgross35 commented on Oct 5, 2024

taiki-e commented on Oct 5, 2024

33 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions