On Thu, Jul 1, 2021 at 11:26 PM Joseph Myers <jos...@codesourcery.com> wrote: > > On Thu, 1 Jul 2021, liuhongt via Gcc-patches wrote: > > > +/* Optimize for code like (_Float16) __builtin_ceif ((float) f16) > > + since it's not handled in frontend. */ > > Much the same comments apply as for sqrt. But in this case, the > conversion code is in match.pd - right now, specific to pairs of types > (float, double) and (float, long double). And it's logically valid for > any pair of same-radix floating-point types, the values of one of which > are a subset of the values of the other (a strict subset, for it actually > to be an interesting optimization). (So when making it apply to more > general types, take care that it does *not* apply to the __ibm128 / > _Float128 pair on powerpc64le, in either order, because neither of those > types has values a subset of the other.) > > (Also, the match.pd code isn't handling roundeven at present, but that > should be a trivial addition to it.)
Note that for non-"standard" float formats emitting builtins would require guaranteed libm support (IIRC we don't have rounding functions in libgcc), so guarding on availability of a machine instruction (optab) for the operation should be tested instead - see my proposed match rule for sqrt and using internal-functions and the direct optab machinery. Richard. > -- > Joseph S. Myers > jos...@codesourcery.com
