`s0` clobber in inline assembly generates incorrect code when used with VLA

[nbdd0121]

This code:

int bar(int *x);

int foo(int s) {
    asm volatile("mv x8, x0" ::: "x8");
    int x[s];
    bar(x);
    return 0;
}

generates this assembly:

foo:
        addi    sp, sp, -16
        sw      ra, 12(sp)
        sw      s0, 8(sp)
        addi    s0, sp, 16
        li      s0, 0 ; asm code
        slli    a0, a0, 2
        addi    a0, a0, 15
        andi    a0, a0, -16
        sub     a0, sp, a0
        mv      sp, a0
        call    bar
        li      a0, 0
        addi    sp, s0, -16 ; use of `s0` while it's clobbered
        lw      ra, 12(sp)
        lw      s0, 8(sp)
        addi    sp, sp, 16
        ret

https://godbolt.org/z/5hKz8KxY8

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

Author: Gary Guo (nbdd0121)

This code: ```c int bar(int *x);

int foo(int s) {
asm volatile("mv x8, x0" ::: "x8");
int x[s];
bar(x);
return 0;
}

generates this assembly:
```asm
foo:
        addi    sp, sp, -16
        sw      ra, 12(sp)
        sw      s0, 8(sp)
        addi    s0, sp, 16
        li      s0, 0 ; asm code
        slli    a0, a0, 2
        addi    a0, a0, 15
        andi    a0, a0, -16
        sub     a0, sp, a0
        mv      sp, a0
        call    bar
        li      a0, 0
        addi    sp, s0, -16 ; use of `s0` while it's clobbered
        lw      ra, 12(sp)
        lw      s0, 8(sp)
        addi    sp, sp, 16
        ret

https://godbolt.org/z/5hKz8KxY8

[jrtc27]

This is intended behaviour but should be warning like it does on AArch64 if you try to clobber fp. GCC also instead just errors if you try to do this, which is arguably better than emitting a warning that it likely won't work.

[topperc]

This is intended behaviour but should be warning like it does on AArch64 if you try to clobber fp. GCC also instead just errors if you try to do this, which is arguably better than emitting a warning that it likely won't work.

Do you know where the warning is implemented?

[jrtc27]

TargetRegisterInfo::isAsmClobberable (used for the warning in AsmPrinter::emitInlineAsm)

[luismarques]

This is intended behaviour but should be warning like it does on AArch64 if you try to clobber fp. GCC also instead just errors if you try to do this, which is arguably better than emitting a warning that it likely won't work.

Is there any reason why that's intended even with the (default) -fomit-frame-pointer? Why can't it just work?

[jrtc27]

This is intended behaviour but should be warning like it does on AArch64 if you try to clobber fp. GCC also instead just errors if you try to do this, which is arguably better than emitting a warning that it likely won't work.

Is there any reason why that's intended even with the (default) -fomit-frame-pointer? Why can't it just work?

I would assume because, by being a reserved register when hasFP returns true, it does not participate in the normal register allocation process and therefore we're not equipped to handle such clobbers without special tracking?

[luismarques]

I would assume because, by being a reserved register when hasFP returns true, it does not participate in the normal register allocation process and therefore we're not equipped to handle such clobbers without special tracking?

That's useful, thanks. But also, that confirms the "intended" is meant only in the sense that it's required to work around a limitation of the current implementation, not due to any fundamental reason. I think it should just work, though I understand it might not be easy to make it so.

[jrtc27]

Yeah. I guess "expected behaviour that's consistent with other targets".