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

[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)) == &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?

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