RFR: 8339741: RISC-V: C ABI breakage for integer on stack [v2]

[Robbin Ehn]

On Tue, 10 Sep 2024 05:14:47 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi please review,
>> 
>> When calling a native function using integers smaller than 64,
>> they must be loaded from a Java stack slot and widen to 64-bit, sign-extended.
>> In the interpreter case we only store 32-bit, which means the top 32-bit are 'random'.
>> In the compiler case we do an ld and grab random top 32-bit.
>> These should be loaded with a lw from Java stack, thus proper sign extended and then stored with sd into the native stack.
>> 
>> I found the intrepter bug first, wrote a test case for it, which found the compiler bug.
>> 
>> Here you can see the difference, both are legal todo from a compiler:
>> https://godbolt.org/z/85aMhja5f
>> Relevant specs:
>> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc
>>> integer scalars narrower than XLEN bits are widened according to the sign of their type up to 32 bits, then sign-extended to XLEN bits.
>> 
>> I checked floats also, they seems fine, but please go ahead and do a check regarding floats.
>> 
>> Passes ./test/hotspot/jtreg/compiler/calls/, runnnig t1.
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Added comment
>  - Merge branch 'master' into c_abi_error
>  - Fixed

Oh, so I have question here:

  } else if (dst.first()->is_stack()) {
    // reg to stack
    sd(src.first()->as_Register(), Address(sp, reg2offset_out(dst.first())));
  } else {
    if (dst.first() != src.first()) {
      sign_extend(dst.first()->as_Register(), src.first()->as_Register(), 32);
    }
  }

The sd is done without any sign extension, hence we must have C ABI representation in the register.
But that means the register to register case, where we have sign_extend(), is actually just a move.
AFAIK this is the case, which I hope, otherwise we have third bug here.
So I think we should use `mv` to be clear about what we are doing.

?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20912#issuecomment-2339650697