Re: [PATCH] Add __builtin_iseqsig()

[Joseph Myers <joseph@codesourcery.com>]

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
joseph@codesourcery.com