On Tue, May 28, 2024 at 9:09 AM Kewen.Lin <li...@linux.ibm.com> wrote: > > Hi, > > on 2024/5/27 20:54, Richard Biener wrote: > > On Mon, May 27, 2024 at 11:37 AM HAO CHEN GUI <guih...@linux.ibm.com> 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 specify acceptable > >> modes for the optab. > >> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652170.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..67407fad37d 100644 > >> --- a/gcc/doc/md.texi > >> +++ b/gcc/doc/md.texi > >> @@ -8557,6 +8557,15 @@ 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 @code{SFmode}, > >> +@code{DFmode}, or @code{TFmode} floating point number and to 0 > > > > It should probably say scalar floating-point mode? But what about the > > result? > > Is any integer mode OK? That's esp. important if this might be used on > > vector modes. > > > >> +otherwise. > >> + > >> +If this pattern @code{FAIL}, a call to the library function > >> +@code{isfinite} is used. > > > > Or it's otherwise inline expanded? Or does this imply targets > > have to make sure to implement the pattern when isfinite is > > not available in libc/libm? I suggest to leave this sentence out, > > we usually only say when a pattern may _not_ FAIL (and usually > > FAILing isn't different from not providing a pattern). > > As Haochen's previous reply, I think there are three cases: > 1) no optab defined, fold in a generic way; > 2) optab defined, SUCC, expand as what it defines; > 3) optab defined, FAIL, generate a library call; > > From above, I had the concern that ports may assume FAILing can > fall back with the generic folding, but it's not actually.
Hmm, but it should. Can you make that work? > Does your comment imply ports usually don't make such assumption > (or they just check what happens for FAIL)? > > 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") > > >
