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
