[PATCHv2] Optab: add isfinite_optab for __builtin_isfinite

Hi,
  This patch adds an optab for __builtin_isfinite. The finite check can be
implemented on rs6000 by a single instruction. It needs an optab to be
expanded to the certain sequence of instructions.

  The subsequent patches will implement the expand on rs6000.

  Compared to previous version, the main change is to document isfinite
in md.texi.
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html

  Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no
regressions. Is this OK for trunk?

Thanks
Gui Haochen

ChangeLog
optab: Add isfinite_optab for isfinite builtin

gcc/
	* builtins.cc (interclass_mathfn_icode): Set optab to isfinite_optab
	for isfinite builtin.
	* optabs.def (isfinite_optab): New.
	* doc/md.texi (isfinite): Document.


patch.diff

Hi,
  Gently ping it.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652170.html

Thanks
Gui Haochen

在 2024/5/20 16:15, HAO CHEN GUI 写道:
> Hi,
>   This patch adds an optab for __builtin_isfinite. The finite check can be
> implemented on rs6000 by a single instruction. It needs an optab to be
> expanded to the certain sequence of instructions.
> 
>   The subsequent patches will implement the expand on rs6000.
> 
>   Compared to previous version, the main change is to document isfinite
> in md.texi.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html
> 
>   Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no
> regressions. Is this OK for trunk?
> 
> Thanks
> Gui Haochen
> 
> ChangeLog
> optab: Add isfinite_optab for isfinite builtin
> 
> gcc/
> 	* builtins.cc (interclass_mathfn_icode): Set optab to isfinite_optab
> 	for isfinite builtin.
> 	* optabs.def (isfinite_optab): New.
> 	* doc/md.texi (isfinite): Document.
> 
> 
> patch.diff
> diff --git a/gcc/builtins.cc b/gcc/builtins.cc
> index f8d94c4b435..b8432f84020 100644
> --- a/gcc/builtins.cc
> +++ b/gcc/builtins.cc
> @@ -2459,8 +2459,9 @@ interclass_mathfn_icode (tree arg, tree fndecl)
>        errno_set = true; builtin_optab = ilogb_optab; break;
>      CASE_FLT_FN (BUILT_IN_ISINF):
>        builtin_optab = isinf_optab; break;
> -    case BUILT_IN_ISNORMAL:
>      case BUILT_IN_ISFINITE:
> +      builtin_optab = isfinite_optab; break;
> +    case BUILT_IN_ISNORMAL:
>      CASE_FLT_FN (BUILT_IN_FINITE):
>      case BUILT_IN_FINITED32:
>      case BUILT_IN_FINITED64:
> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> index 5730bda80dc..8ed70b3feea 100644
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -8557,6 +8557,11 @@ operand 2, greater than operand 2 or is unordered with operand 2.
> 
>  This pattern is not allowed to @code{FAIL}.
> 
> +@cindex @code{isfinite@var{m}2} instruction pattern
> +@item @samp{isfinite@var{m}2}
> +Set operand 0 to nonzero if operand 1 is a finite floating-point
> +number and to 0 otherwise.
> +
>  @end table
> 
>  @end ifset
> diff --git a/gcc/optabs.def b/gcc/optabs.def
> index ad14f9328b9..dcd77315c2a 100644
> --- a/gcc/optabs.def
> +++ b/gcc/optabs.def
> @@ -352,6 +352,7 @@ OPTAB_D (fmod_optab, "fmod$a3")
>  OPTAB_D (hypot_optab, "hypot$a3")
>  OPTAB_D (ilogb_optab, "ilogb$a2")
>  OPTAB_D (isinf_optab, "isinf$a2")
> +OPTAB_D (isfinite_optab, "isfinite$a2")
>  OPTAB_D (issignaling_optab, "issignaling$a2")
>  OPTAB_D (ldexp_optab, "ldexp$a3")
>  OPTAB_D (log10_optab, "log10$a2")

Hi,

on 2024/5/20 16:15, HAO CHEN GUI wrote:
> Hi,
>   This patch adds an optab for __builtin_isfinite. The finite check can be
> implemented on rs6000 by a single instruction. It needs an optab to be
> expanded to the certain sequence of instructions.
> 
>   The subsequent patches will implement the expand on rs6000.
> 
>   Compared to previous version, the main change is to document isfinite
> in md.texi.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html
> 
>   Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no
> regressions. Is this OK for trunk?
> 
> Thanks
> Gui Haochen
> 
> ChangeLog
> optab: Add isfinite_optab for isfinite builtin
> 
> gcc/
> 	* builtins.cc (interclass_mathfn_icode): Set optab to isfinite_optab
> 	for isfinite builtin.
> 	* optabs.def (isfinite_optab): New.
> 	* doc/md.texi (isfinite): Document.
> 
> 
> patch.diff
> diff --git a/gcc/builtins.cc b/gcc/builtins.cc
> index f8d94c4b435..b8432f84020 100644
> --- a/gcc/builtins.cc
> +++ b/gcc/builtins.cc
> @@ -2459,8 +2459,9 @@ interclass_mathfn_icode (tree arg, tree fndecl)
>        errno_set = true; builtin_optab = ilogb_optab; break;
>      CASE_FLT_FN (BUILT_IN_ISINF):
>        builtin_optab = isinf_optab; break;
> -    case BUILT_IN_ISNORMAL:
>      case BUILT_IN_ISFINITE:
> +      builtin_optab = isfinite_optab; break;
> +    case BUILT_IN_ISNORMAL:
>      CASE_FLT_FN (BUILT_IN_FINITE):
>      case BUILT_IN_FINITED32:
>      case BUILT_IN_FINITED64:
> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> index 5730bda80dc..8ed70b3feea 100644
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -8557,6 +8557,11 @@ operand 2, greater than operand 2 or is unordered with operand 2.
> 
>  This pattern is not allowed to @code{FAIL}.
> 
> +@cindex @code{isfinite@var{m}2} instruction pattern
> +@item @samp{isfinite@var{m}2}
> +Set operand 0 to nonzero if operand 1 is a finite floating-point
> +number and to 0 otherwise.
> +

Does this require "This pattern is not allowed to FAIL."?

I guess yes?  Since if it's decided to go with this pattern
expanding, there is no fall back?

BR,
Kewen


>  @end table
> 
>  @end ifset
> diff --git a/gcc/optabs.def b/gcc/optabs.def
> index ad14f9328b9..dcd77315c2a 100644
> --- a/gcc/optabs.def
> +++ b/gcc/optabs.def
> @@ -352,6 +352,7 @@ OPTAB_D (fmod_optab, "fmod$a3")
>  OPTAB_D (hypot_optab, "hypot$a3")
>  OPTAB_D (ilogb_optab, "ilogb$a2")
>  OPTAB_D (isinf_optab, "isinf$a2")
> +OPTAB_D (isfinite_optab, "isfinite$a2")
>  OPTAB_D (issignaling_optab, "issignaling$a2")
>  OPTAB_D (ldexp_optab, "ldexp$a3")
>  OPTAB_D (log10_optab, "log10$a2")

On Mon, May 27, 2024 at 4:10 AM HAO CHEN GUI <guihaoc@linux.ibm.com> wrote:
>
> Hi,
>   Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652170.html
>
> Thanks
> Gui Haochen
>
> 在 2024/5/20 16:15, HAO CHEN GUI 写道:
> > Hi,
> >   This patch adds an optab for __builtin_isfinite. The finite check can be
> > implemented on rs6000 by a single instruction. It needs an optab to be
> > expanded to the certain sequence of instructions.
> >
> >   The subsequent patches will implement the expand on rs6000.
> >
> >   Compared to previous version, the main change is to document isfinite
> > in md.texi.
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html
> >
> >   Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no
> > regressions. Is this OK for trunk?
> >
> > Thanks
> > Gui Haochen
> >
> > ChangeLog
> > optab: Add isfinite_optab for isfinite builtin
> >
> > gcc/
> >       * builtins.cc (interclass_mathfn_icode): Set optab to isfinite_optab
> >       for isfinite builtin.
> >       * optabs.def (isfinite_optab): New.
> >       * doc/md.texi (isfinite): Document.
> >
> >
> > patch.diff
> > diff --git a/gcc/builtins.cc b/gcc/builtins.cc
> > index f8d94c4b435..b8432f84020 100644
> > --- a/gcc/builtins.cc
> > +++ b/gcc/builtins.cc
> > @@ -2459,8 +2459,9 @@ interclass_mathfn_icode (tree arg, tree fndecl)
> >        errno_set = true; builtin_optab = ilogb_optab; break;
> >      CASE_FLT_FN (BUILT_IN_ISINF):
> >        builtin_optab = isinf_optab; break;
> > -    case BUILT_IN_ISNORMAL:
> >      case BUILT_IN_ISFINITE:
> > +      builtin_optab = isfinite_optab; break;
> > +    case BUILT_IN_ISNORMAL:
> >      CASE_FLT_FN (BUILT_IN_FINITE):
> >      case BUILT_IN_FINITED32:
> >      case BUILT_IN_FINITED64:
> > diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> > index 5730bda80dc..8ed70b3feea 100644
> > --- a/gcc/doc/md.texi
> > +++ b/gcc/doc/md.texi
> > @@ -8557,6 +8557,11 @@ operand 2, greater than operand 2 or is unordered with operand 2.
> >
> >  This pattern is not allowed to @code{FAIL}.
> >
> > +@cindex @code{isfinite@var{m}2} instruction pattern
> > +@item @samp{isfinite@var{m}2}
> > +Set operand 0 to nonzero if operand 1 is a finite floating-point
> > +number and to 0 otherwise.

Please specify acceptable modes.

> > +
> >  @end table
> >
> >  @end ifset
> > diff --git a/gcc/optabs.def b/gcc/optabs.def
> > index ad14f9328b9..dcd77315c2a 100644
> > --- a/gcc/optabs.def
> > +++ b/gcc/optabs.def
> > @@ -352,6 +352,7 @@ OPTAB_D (fmod_optab, "fmod$a3")
> >  OPTAB_D (hypot_optab, "hypot$a3")
> >  OPTAB_D (ilogb_optab, "ilogb$a2")
> >  OPTAB_D (isinf_optab, "isinf$a2")
> > +OPTAB_D (isfinite_optab, "isfinite$a2")
> >  OPTAB_D (issignaling_optab, "issignaling$a2")
> >  OPTAB_D (ldexp_optab, "ldexp$a3")
> >  OPTAB_D (log10_optab, "log10$a2")

Hi Kewen,
  Thanks for your comments.

在 2024/5/27 11:18, Kewen.Lin 写道:
> Does this require "This pattern is not allowed to FAIL."?
> 
> I guess yes?  Since if it's decided to go with this pattern
> expanding, there is no fall back?

  The builtin is inline folded if the optab doesn't exist on
the target. Otherwise, it is expanded by target specific
insns. If it fails at expand, the library is called. It can't
fall back to inline folding when it fails at expand. I am not
sure whether it should be marked "allowed to FAIL" or not.

  Could anyone advice me?

Thanks
Gui Haochen

Hi Haochen,

on 2024/5/27 15:22, HAO CHEN GUI wrote:
> Hi Kewen,
>   Thanks for your comments.
> 
> 在 2024/5/27 11:18, Kewen.Lin 写道:
>> Does this require "This pattern is not allowed to FAIL."?
>>
>> I guess yes?  Since if it's decided to go with this pattern
>> expanding, there is no fall back?
> 
>   The builtin is inline folded if the optab doesn't exist on
> the target. Otherwise, it is expanded by target specific
> insns. If it fails at expand, the library is called. It can't
> fall back to inline folding when it fails at expand. I am not
> sure whether it should be marked "allowed to FAIL" or not.

Ah, so it's allowed to FAIL, just not falling back with the
generic folding way, then it should not be marked with "not
allowed to FAIL" clearly.  Maybe we can note that "FAIL" makes
it call the according library function instead (avoiding the
possible assumption it will fall back with generic folding).

BR,
Kewen

> 
>   Could anyone advice me?
> 
> Thanks
> Gui Haochen