Cranelift: Function call causes unexpected value changes on riscv64

[akldc]

.clif Test Case

test optimize    
    set opt_level=none
    set preserve_frame_pointers=true
    set enable_multi_ret_implicit_sret=true           

function u1:1(i64) -> i64 fast {
    ss0 = explicit_slot 32
    ss1 = explicit_slot 32
    const0 = 0xbdea39e5631c0104d92f26de921e6dbf

block0(v2: i64):
    v1 = iconst.i64 -5608073308517523622
    v3 = vconst.f32x4 const0
    stack_store v1, ss0
    stack_store v1, ss0+8
    stack_store v1, ss0+16
    stack_store v1, ss0+24
    stack_store v3, ss1
    stack_store v3, ss1+16
    return v2
}

function %main() -> i16x8, f64x2 fast {
    sig0 = (i64) -> i64 fast
    fn0 = u1:1 sig0
    const0 = 0x00110022003300440055006600770088

block0:
    v1 = iconst.i64 0x1f96_3ea8_4eb6_5f81
    v11 = vconst.i16x8 const0
    v13 = vconst.f32x4 const0
    v26 = fvpromote_low v13
    v45 = call fn0(v1)
    return  v11, v26
}

; print: %main()

Result

Run this test case on four architectures.

[x86    ] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]
[aarch64] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]
[riscv64] %main() -> [0x000000000000002e0000555500770088, 0x00005555568fb3100000000000000000]
[s390x  ] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]

If you remove the instruction v45 = call fn0(v1) and re-run the case, it works as expected.

[x86    ] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]
[aarch64] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]
[riscv64] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]
[s390x  ] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]

So, on the riscv64 architecture, calling the function u1:1 changes the values of v11 and v26.

[alexcrichton]

cc #11026 which has a test that I ignored on riscv64 and may be related to this issue (unsure though)

[akldc]

@alexcrichton It seems that the bug in #11024 has been fixed, but this issue still remains.

[alexcrichton]

Oh that's expected yeah, the test I added in that PR failed on riscv64 so I had to ignore it on riscv64, and my suspicion is that it was related to one of the issues you opened. (the bugfix was only for x86)

[alexcrichton]

Ah this one turned out to be a relatively easy fix!