Incorrect code generated from inline assembly with `inout` register on riscv32im-unknown-none-elf

[shkoo]

I tried compiling this code with a target of riscv32im-unknown-none-elf:

#![no_std]

static mut MY_BUFFER: [u32; 4] = [0u32; 4];

#[no_mangle]
unsafe fn using_inout() {
    let mut start = MY_BUFFER.as_mut_ptr();
    ::core::arch::asm!(
            "ecall",
            inout("a0") start);
    _ = start;
}

The assembly generated is incorrect, since it doesn't add in the lower 16 bits of the address of MY_BUFFER before calling the ecall:

using_inout:
        lui     a0, %hi(example::MY_BUFFER::he36bd30b506a9b69)
        ecall
        ret

As a workaround, changing the inout to inlateout seems to fix the problem:

using_inlateout:
        lui     a0, %hi(example::MY_BUFFER::he36bd30b506a9b69)
        addi    a0, a0, %lo(example::MY_BUFFER::he36bd30b506a9b69)
        ecall
        ret

Here is a compiler explorer link for rust nightly that demonstrates the problem:

https://godbolt.org/z/xMjoTo5oY

(For reference in case it gets fixed in nightly, it's also present in rust 1.80.0)

[tgross35]

I haven't looked into this too much yet, but do you know if it reproduces using C's inline assembly fed through clang? This seems like it could be an LLVM problem.

[flaub]

It appears that this bug starts to appear in 1.77.

Using riscv32i-unknown-none-elf target:

1.76: https://godbolt.org/z/bKosKqvfW
1.77: https://godbolt.org/z/MYacc9na7

[flaub]

Could it be that this is the same underlying issue?
#126221

[tgross35]

Did you mean between 1.77 and 1.78? The two links look the same to me.

It looks like this has to be a regression in LLVM, which was bumped to version 18 in 1.78, because we seem to generate the exact same IR. Could you file an issue with LLVM?

https://godbolt.org/z/Te9efcnMz

Could it be that this is the same underlying issue? #126221

It looks like it, I will close that one because this one has more detail.