> On 12/20/23 4:17 AM, Jin Ma wrote:
> > We don't have SI -> BF library functions, use SI -> SF -> BF
> > instead. Although this can also be implemented in a target
> > machine description, it is more appropriate to move
> > into target independent code.
> >
> > gcc/ChangeLog:
> >
> > * optabs.cc (expand_float): Split SI -> BF into SI -> SF -> BF.
> > ---
> > gcc/optabs.cc | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/gcc/optabs.cc b/gcc/optabs.cc
> > index 6a34276c239..c58a0321bbd 100644
> > --- a/gcc/optabs.cc
> > +++ b/gcc/optabs.cc
> > @@ -5727,6 +5727,19 @@ expand_float (rtx to, rtx from, int unsignedp)
> > if (is_narrower_int_mode (GET_MODE (from), SImode))
> > from = convert_to_mode (SImode, from, unsignedp);
> >
> > +#ifdef HAVE_SFmode
> > + if (REAL_MODE_FORMAT (GET_MODE (to)) == &arm_bfloat_half_format
> > + && REAL_MODE_FORMAT (SFmode) == &ieee_single_format
> > + && GET_MODE (from) == SImode)
> > + /* We don't have SI -> BF library functions, use SI -> SF -> BF
> > + instead. */
> > + {
> > + target = gen_reg_rtx (SFmode);
> > + expand_float (target, from, unsignedp);
> > + goto done;
> > + }
> > +#endif
> Why do you have the #ifdef HAVE_SFmode? That seems odd, I think the
> only place we do anything like that is in targhooks. Why did you add
> those cpp conditionals?
Hi, jeff
I'm sorry I haven't noticed this email for so long. For this patch, my
original idea was to use SF to complete the SI to BF conversion. This
is because RSICV did not support that when the patch was submitted, and
the relevant soft floating point library '__floatsibf' was not defined,
so I used a new pattern to do this. The soft floating-point library
'__floatsibf' has been added now, which seems to be the most correct
approach. So this patch is no longer meaningful in this respect.
Ref:
https://patchwork.ozlabs.org/project/gcc/patch/20230919084444.2089-1-ji...@linux.alibaba.com/
BR,
Jin
>
> Bring the comment "We don't have SI -> BF ..." inside the open curly and
> indent it two more spaces. That should be more consistent with GCC style.
>
> So generally OK. I suspect this can move forward once we figure out why
> you added those cpp conditionals and fix the formatting nit.
>
> jeff
