Re: [RFC 1/2] RISC-V: Add support for _Bfloat16.

[Jeff Law <jeffreyalaw@gmail.com>]

On 10/9/23 00:18, Jin Ma wrote:

>>> +;; The conversion of DF to BF needs to be done with SF if there is a
>>> +;; chance to generate at least one instruction, otherwise just using
>>> +;; libfunc __truncdfbf2.
>>> +(define_expand "truncdfbf2"
>>> +  [(set (match_operand:BF     0 "register_operand" "=f")
>>> +       (float_truncate:BF
>>> +           (match_operand:DF 1 "register_operand" " f")))]
>>> +  "TARGET_DOUBLE_FLOAT || TARGET_ZDINX"
>>> +  {
>>> +    convert_move (operands[0],
>>> +		  convert_modes (SFmode, DFmode, operands[1], 0), 0);
>>> +    DONE;
>>> +  })
>> So for conversions to/from BFmode, doesn't generic code take care of
>> this for us?  Search for convert_mode_scalar in expr.cc. That code will
>> utilize SFmode as an intermediate step just like your expander.   Is
>> there some reason that generic code is insufficient?
>>
>> Similarly for the the other conversions.
> 
> As far as I can see, the function 'convert_mode_scalar' doesn't seem to be perfect for
> dealing with the conversions to/from BFmode. It can only handle BF to HF, SF, DF and
> SF to BF well, but the rest of the conversion without any processing, directly using
> the libcall.
> 
> Maybe I should choose to enhance its functionality? This seems to be a
> good choice, I'm not sure.My recollection was that BF could be converted to/from SF trivially and 
if we wanted BF->DF we'd first convert to SF, then to DF.

Direct BF<->DF conversions aren't actually important from a performance 
standpoint.  So it's OK if they have an extra step IMHO.

jeff