On Mon, 29 Jan 2018, vladimir.mezent...@oracle.com wrote: > > What about powerpc __divkc3? > > > > What was the rationale for using soft-fp rather than adding appropriate > > built-in functions as suggested in a comment? > > I had a version with built-in functions and I can restore it. > > Let's design what we want to use soft-fp or built-in function. > I'd prefer to use built-in functions but performance is in two times worse. > > The test below demonstrates performance degradation:
So, this is comparing __builtin_frexp (extracting both exponent and mantissa, including appropriate handling of exponents of subnormal values) with just extracting the exponent and with no special handling of zero / infinity / NaN / subnormal values. We need to consider what functionality is actually needed for this scaling, if we do wish to use such scaling based on integer exponents. If what's needed corresponds exactly to some standard functions such as ilogb and scalbn with all their special cases, then built-in versions of those standard functions may make sense. If what's needed does not correspond to standard functions and does not need to handle such special cases, that's more of an indication for examining the representation in libgcc - but it's still necessary to handle the many different variant floating-point formats supported, or to safely avoid using the new code for formats it can't handle. -- Joseph S. Myers jos...@codesourcery.com