RFR: 8318227: RISC-V: C2 ConvHF2F

[Hamlin Li]

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

>> Thanks for the suggestion, it make sense.
>> 
>> Just I'm not sure if there is a straight way to implement it currently. Following is what I've done, but blocked, please help to share your opinion.
>>  
>> To jump to stub code to process NaN case, the stub code need to use specific register for `src` and `dst`, as `dst` is a FloatRegister, so need a way to specify a float register when matching `ConvHF2F` in ad file. I tried to add a `fRegF_F10` to enable specify a float register, but it does not work well. Some error occurs for fastdebug version:
>> 
>> 
>> ----------System.out:(47/2030)----------
>> Start ...
>> o558  SubF  === _ o515 o559  [[ o557 ]]
>> 
>> --N: o558  SubF  === _ o515 o559  [[ o557 ]]
>> 
>>    --N: o515  MoveI2F  === _ o681  [[ o470 o484 o620 o620 o618 o579 o558 o530 o434 4 10 10 ]]
>>    FREGF  0  FREGF
>>    FREGF_F10  0  FREGF_F10
>> 
>>    --N: o559  ConvHF2F  === _ o560  [[ o558 ]]  #float
>>    FREGF_F10  100  convHF2F_reg_reg
>> 
>>       --N: o560  RShiftI  === _ o561 o209  [[ o559 o434 4 ]]
>>       IREGI  0  IREGI
>>       IREGINOSP  0  IREGINOSP
>>       IREGI_R10  0  IREGI_R10
>>       IREGI_R11  0  IREGI_R11
>>       IREGI_R12  0  IREGI_R12
>>       IREGI_R13  0  IREGI_R13
>>       IREGI_R14  0  IREGI_R14
>>       IREGIORL2I  0  IREGI
>>       IREGIORL  0  IREGI
>>       IREGILNP  0  IREGI
>>       IREGILNPNOSP  0  IREGINOSP
>> 
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (/home/hamlin/workspace/repos/github/jdk/src/hotspot/share/opto/matcher.cpp:1727), pid=2212108, tid=2212156
>> #  assert(false) failed: bad AD file
>
> 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).

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

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