RFR: 8318227: RISC-V: C2 ConvHF2F

[Quan Anh Mai]

On Fri, 24 Nov 2023 17:53:11 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> The workaround I can use is to mv the result back to `dst` when comes back from stub code, like below:
>> 
>>   bind(nan_case);
>>   // input:   x11
>>   // output:  x10
>>   RuntimeAddress stub = RuntimeAddress(StubRoutines::riscv::float16_to_float_process_nan());
>>   assert(stub.target() != nullptr, "float16_to_float_process_nan stub has not been generated");
>>   address call = trampoline_call(stub);
>>   fmv_w_x(dst, x10);
>> 
>> 
>> But, this seems to me a bit more complicated.
>
> And at the other side, the nan processing code is almost the same size as trampoline calling code, is it worth to do it in this case?
> 
> Although I can image in another patch for floatToFloat16, it's worth to give it a try by using a out-of-line stub, as in that case, the nan processing a bit longer than float16ToFloat (i.e. this patch).

You can take a look at x86 implementation of ConvF2I node which takes advantages of a general stub mechanism in C2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16802#discussion_r1404704835