RISC-V intrinsics with one or more target features are not inlined

[brkydnc]

The Problem

The compiler does not inline RISC-V intrinsics that can be enabled with one or more target features (i.e. #[target_feature(enable = "zkne", enable = "zknd")]) unless all of them are present.

Expected Behavior

At least one enabled feature should be enough for the compiler to generate inlined code.

Explanation

RISC-V intrinsics such as sha512sig0 require only one target feature:

#[target_feature(enable = "zknh")]
pub unsafe fn sha512sig0(rs1: u64) -> u64;

When zknh is enabled, the compiler inlines the intrinsic with the appropriate instruction on nightly (https://godbolt.org/z/Kozx3KE11):

example::main::hb1a6ee9bd645943a:
        addi    sp, sp, -16
        sha512sig0      a0, zero
        sd      a0, 8(sp)
        addi    a0, sp, 8
        addi    sp, sp, 16
        ret

Unfortunately, this is not the case for intrinsics that can be enabled by one or more target features. Let's take a look at aes64ks2:

#[target_feature(enable = "zkne", enable = "zknd")]
pub unsafe fn aes64ks2(rs1: u64, rs2: u64) -> u64;

The documentation states that the intrinsic is "safe to use if the zkne OR zknd target feature is present." which means that enabling at least one of them should be enough to inline the intrinsic.

However, the compiler exhibits this behavior only if two of them are enabled at the same time.

The compiler generates a stub if only one of zkne (https://godbolt.org/z/5TxeKo1sG), or zknd (https://godbolt.org/z/KKqz8MWYY) is enabled:

core::core_arch::riscv64::zk::aes64ks2::ha6614eafefa6ee36:
        aes64ks2        a0, zero, zero
        ret

example::main::hb1a6ee9bd645943a:
        addi    sp, sp, -16
        sd      ra, 8(sp)
        call    core::core_arch::riscv64::zk::aes64ks2::ha6614eafefa6ee36
        sd      a0, 0(sp)
        mv      a0, sp
        ld      ra, 8(sp)
        addi    sp, sp, 16
        ret

If they are both enabled, the compiler inlines the intrinsic as expected (https://godbolt.org/z/3fEjfr1v8):

example::main::hb1a6ee9bd645943a:
        addi    sp, sp, -16
        aes64ks2        a0, zero, zero
        sd      a0, 8(sp)
        addi    a0, sp, 8
        addi    sp, sp, 16
        ret

Meta

Here is the output of the compiler:

rustc 1.87.0-nightly (5bc623145 2025-02-16)
binary: rustc
commit-hash: 5bc62314547c7639484481f62f218156697cfef0
commit-date: 2025-02-16
host: x86_64-unknown-linux-gnu
release: 1.87.0-nightly
LLVM version: 19.1.7

[bjorn3]

I'm pretty sure #[target_feature(enable = "zkne", enable = "zknd")] is interpreted as enabling both the zkne and zknd features within the body of the intrinsic implementation and thus requiring both to be enabled when calling it. I don't think we have support for enabling one or the other feature.

[sayantn]

We do not have support for ORing target features. So the function requires both zkne and zknd. But if I am not too wrong, this is incorrect behaviour. The riscv manual specifies that this function should be available whenever any one of the features is available.

See the scalar crypto doc for riscv https://github.com/riscv/riscv-crypto/releases/tag/v1.0.1-scalar

cc @Amanieu

[brkydnc]

Is there any non-trivial reason why Rust does not support this behavior?

[bjorn3]

When codegening the function

#[target_feature(biskeshed_enable_one_of("zkne", "zknd")]
pub unsafe fn aes64ks2(rs1: u64, rs2: u64) -> u64 {
   // ...
}

which of the two features should be enabled? You have to enable at least one of them to be able to call the inner intrinsic, but there is no way to know which of the two features the caller has enabled. The aes64ks2 function is not guaranteed to be inlined so just inheriting the feature of the function it were to be inlined into doesn't work.

[Amanieu]

ORing features is functionally equivalent to having a new feature called zkne_or_zknd which both zkne and zknd depend on. We could expose this as an explicit feature, or implicitly via some syntax (e.g. target_feature(enable = "zkne|zknd")).

Incidentally this is very similar to rust-lang/compiler-team#778.

[bjorn3]

Does LLVM have any support for that?

[brkydnc]

Yes, it has the support here and here.