On Mon, 31 Oct 2022, FX via Gcc-patches wrote: > - rounded conversions: converting, from an integer or floating point > type, into another floating point type, with specific rounding mode > passed as argument
These don't have standard C names. The way to do these in C would be using the FENV_ROUND pragma around a conversion, but we don't support any of the standard pragmas including those from C99 and they would be a large project (cf. Marc Glisse's -ffenv-access patches from August 2020 - although some things in FENV_ACCESS are probably rather orthogonal to FENV_ROUND, I expect what's required in terms of preventing unwanted code movement across rounding mode changes is similar). It might be possible to add built-in functions for such conversions without needing the FENV_ROUND machinery, if you make them expand to insn patterns (with temporary rounding mode changes) that are arranged so the compiler can't split them up. (There's a principle of not introducing libm dependencies in code not using any <math.h>, <fenv.h> or <complex.h> functions or corresponding built-in functions, which would be an issue for generating calls to fesetround, inline or in libgcc, from such an operation. But arguably, even if FENV_ROUND shouldn't introduce such dependencies - my assumption being that FENV_ROUND should involve target-specific inline implementations of the required rounding mode changes - it might be OK to document some GCC-specific built-in function as doing so.) > - conversion to integer: converting, from a floating point type, into an > integer type, with specific rounding mode passed as argument See the fromfp functions (signed and unsigned versions, versions with and without raising inexact, rounding mode specified as one of the FP_INT_* macros from <math.h>). The versions in TS 18661-1 produced results in an integer type (intmax_t / uintmax_t, with the actual width for the conversion passed as an argument). *But* C2X changed that to return the result in a floating-point type instead (as part of reducing the use of intmax_t in interfaces) - I haven't yet implemented that change in glibc. So the way to do such a conversion to an integer type in C2X involves calling such a function and then converting its result to that integer type. GCC certainly knows about handling such a pair (<math.h> function, conversion of its result) as a built-in function (e.g. __builtin_iceil). My guess is that in most cases only selected calls would be expanded inline - calls where not only is there an appropriate conversion to an integer type (matching, or maybe wider than, the width passed to the function), but where also the function, rounding mode and width together match an operation for which there is a hardware instruction, with other cases (including ones where the rounding mode or width aren't constant) ending up as runtime calls (unless optimized for constant arguments). So while the interfaces exist in C2X, the built-in function support in GCC may be fairly complicated, with the existence of the older TS 18661-1 version of the functions complicating things further. > - IEEE operations corresponding to nextDown and nextUp (or are those > already available? I have not checked the fine print) nextdown and nextup have been in glibc since version 2.24. I expect that adding built-in functions that optimize them for constant arguments would be straightforward (that doesn't help if what you actually want it some way to support those operations at runtime for targets without the functions in libm, of course). -- Joseph S. Myers jos...@codesourcery.com
