Re: [PATCH v3 1/5] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578]

[Joseph Myers <joseph@codesourcery.com>]

On Thu, 23 Nov 2023, Xi Ruoyao wrote:

> Indeed...  It seems the FE will only generate __builtin_irintf when -
> fno-math-errno -funsafe-math-optimizations.
> 
> But I cannot see why this is necessary (at least for us): the rintf
> function does not set errno at all, and to me using vftint.w.s here is
> safe: if the rounded result can be represented as a 32-bit int,
> obviously there is no issue;  otherwise, per C23 section F.4 we should
> raise FE_INVALID and produce unspecified result.  It seems our ftint.w.s
> instruction has the required semantics.

The rint functions indeed don't set errno (don't have domain or range 
errors, at least if you ignore the option for signaling NaNs arguments to 
be domain errors - which is in TS 18661-1, but not what glibc does, and 
not in C23).

The lrint / llrint functions should logically set errno for a domain error 
in the cases where they raise "invalid".  That they don't in glibc is 
glibc bug 6798.  And __builtin_irint functions can fall back to calling 
lrint functions if not expanded inline.  So the potential for errno 
setting explains why -fno-math-errno is required.

I don't see an obvious need for -funsafe-math-optimizations here - but at 
least -fno-trapping-math should be needed in some cases.  That's because 
rint raises "inexact" for noninteger argument - but lrint doesn't raise 
"inexact" when raising "invalid".  So if, for example, long is 32-bit and 
the floating type in use is double, calling rint for a noninteger argument 
too large for long, and then converting to a 32-bit signed integer type 
(long or int), raises both "inexact" and "invalid" - but a direct call to 
lrint raises such "invalid".

There are plausible arguments for both -fno-math-errno and 
-fno-trapping-math as defaults, or at least a subset of -fno-trapping-math 
(such as allowing code transformations that don't raise new exceptions but 
might lose some exceptions).

The comment in convert.cc about why -funsafe-math-optimizations is 
required says:

  /* Convert e.g. (long)round(d) -> lround(d).  */
  /* If we're converting to char, we may encounter differing behavior
     between converting from double->char vs double->long->char.
     We're in "undefined" territory but we prefer to be conservative,
     so only proceed in "unsafe" math mode.  */
  if (optimize
      && (flag_unsafe_math_optimizations
          || (long_integer_type_node
              && outprec >= TYPE_PRECISION (long_integer_type_node))))

I think that we should not try to guarantee particular results for such 
out-of-range conversions (unspecified value plus "invalid" given Annex F, 
or undefined in the base standard).

There are various known bugs in Bugzilla for cases where a single 
computation in the abstract machine that produces not-fully-specified 
results gets duplicated and the generated code ends up executing both 
duplicates, with different results from both, while other parts of the 
code expect the single computation in the abstract machine to have a 
single result, so assume the two values generated are the same when they 
are not.  But I wouldn't expect those bugs to be addressed by guaranteeing 
that a given result, maybe matching hardware, is given globally from any 
such computation; it would seem more likely to address them by somehow 
preventing a single computation in the abstract machine from producing 
multiple different results in the actual execution, when it's a 
computation (such as a possibly out-of-range floating conversion to 
integer) for which the results are not fully specified.

-- 
Joseph S. Myers
joseph@codesourcery.com