aarch64: `dit` target feature cannot be reliably en/disabled from assembly

[folkertdev]

The rust graviola crate defines this function

#[target_feature(enable = "dit")]
unsafe fn write(on: u32) {
    if on > 0 {
        // SAFETY: `msr DIT, _` is defined only if `dit` cpu feature is supported
        unsafe { core::arch::asm!("msr DIT, #1") }
    } else {
        // SAFETY: `msr DIT, _` is defined only if `dit` cpu feature is supported
        unsafe { core::arch::asm!("msr DIT, #0") }
    }
}

The target_feature annotation makes the msr DIT instructions work inside the body. In a function without that annotation, LLVM would error.

But, it currently appears to be impossible to write this function reliably using global inline assembly. The standard mechanism doesn't work:

std::arch::global_asm!(".arch_extension dit");

errors with

error: unsupported architectural extension: dit
  |
note: instantiated into assembly here
 --> <inline asm>:1:17
  |
1 | .arch_extension dit
  |                 ^

One way we've found to make the code compile is to use .arch

#[unsafe(naked)]
unsafe extern "C" fn write() {
    core::arch::naked_asm!(
        ".arch armv8.4-a",
        "msr DIT, #0",
        "ret"
    ) 
}

However .arch has no stack-like mechanism to "pop" a state and return to a previous one. Hence, .arch cannot be used reliably. Actually even .arch_extension doesn't have such a mechanism. Many other targets do.

So, can LLVM provide a reliable way to toggle this target feature from inline assembly, preferably something like what riscv and powerpc do with a stack of features. s390x recently added support for a similar mechanism #129053.

see also rust-lang/rust#137720 for examples of how other targets deal with toggling target features in assembly. This concrete problem came up in rust-lang/rustc_codegen_cranelift#1586

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: Folkert de Vries (folkertdev)

The rust [graviola](https://github.com/ctz/graviola/blob/3fe81f602eaf454e5e7fde18f6978913fabd18d5/graviola/src/low/aarch64/cpu.rs#L220-L229) crate defines this function

#[target_feature(enable = "dit")]
unsafe fn write(on: u32) {
    if on > 0 {
        // SAFETY: `msr DIT, _` is defined only if `dit` cpu feature is supported
        unsafe { core::arch::asm!("msr DIT, #<!-- -->1") }
    } else {
        // SAFETY: `msr DIT, _` is defined only if `dit` cpu feature is supported
        unsafe { core::arch::asm!("msr DIT, #<!-- -->0") }
    }
}

The target_feature annotation makes the msr DIT instructions work inside the body. In a function without that annotation, LLVM would error.

But, it currently appears to be impossible to write this function reliably using global inline assembly. The standard mechanism doesn't work:

std::arch::global_asm!(".arch_extension dit");

errors with

error: unsupported architectural extension: dit
  |
note: instantiated into assembly here
 --> <inline asm>:1:17
  |
1 | .arch_extension dit
  |                 ^

One way we've found to make the code compile is to use .arch

#[unsafe(naked)]
unsafe extern "C" fn write() {
    core::arch::naked_asm!(
        ".arch armv8.4-a",
        "msr DIT, #<!-- -->0",
        "ret"
    ) 
}

However .arch has no stack-like mechanism to "pop" a state and return to a previous one. Hence, .arch cannot be used reliably. Actually even .arch_extension doesn't have such a mechanism. Many other targets do.

So, can LLVM provide a reliable way to toggle this target feature from inline assembly, preferably something like what riscv and powerpc do with a stack of features. s390x recently added support for a similar mechanism #129053.

see also rust-lang/rust#137720 for examples of how other targets deal with toggling target features in assembly. This concrete problem came up in rust-lang/rustc_codegen_cranelift#1586

[efriedma-quic]

llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp has a map ExtensionMap for the extensions supported by the asm parser. This is somehow completely separate from the extension list we use in other contexts, like parsing -march flags; we should probably look at unifying that.

For push/pop... I guess we can add that? Not sure how important it is.

[folkertdev]

we should probably look at unifying that.

That would be awesome!

For push/pop... I guess we can add that? Not sure how important it is.

It may not have come up that much in C (though, I'd have no way of truly knowing) but for rust it's extremely annoying that arm32 and aarch64 don't have a good mechanism for pushing/popping target features. I suspect that is because in rust it is very common to write cross-platform libraries, and rust has a more fine-grained approach for target features.

So, I can't determine your priorities, but from the rust side of things, we'd really appreciate this feature.