Re:[PATCH] Support libcall __float{,un}sibf by SF when it is not supported for _bf16

2024-06-05 Thread Jin Ma
> 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)) == _bfloat_half_format
> > +   && REAL_MODE_FORMAT (SFmode) == _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/2023091908.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

Re: [PATCH] Support libcall __float{,un}sibf by SF when it is not supported for _bf16

2024-05-26 Thread Jeff Law




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)) == _bfloat_half_format
+ && REAL_MODE_FORMAT (SFmode) == _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?


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


Re:[PATCH] Support libcall __float{,un}sibf by SF when it is not supported for _bf16

2024-01-09 Thread Jin Ma
I apologize for not attaching a reference link.

Ref:
https://patchwork.ozlabs.org/project/gcc/patch/2023091908.2089-1-ji...@linux.alibaba.com/
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641119.html

BR
Jin


Re:[PATCH] Support libcall __float{,un}sibf by SF when it is not supported for _bf16

2024-01-09 Thread Jin Ma
ping