llvm dev - Jan 2020 - Floating point semantic modes

Yes, you’re probably right about this. I was originally thinking of FENV_ACCESS
as a fully strict mode of operation, but what you’re suggesting aligns with what
Cameron suggested and even some of my own reasoning on other points. So, let me
amend my previous proposal to say:

STDC FENV_ACCESS {ON|OFF}
  Patch in progress. I think ON should force the following:
    except_behavior { strict }
    fenv_access { on }
    rounding_mode { dynamic }
  Other modes should be unchanged.

Thanks,
Andy

From: Serge Pavlov <sepavloff at gmail.com>
Sent: Wednesday, January 29, 2020 9:34 AM
To: Kaylor, Andrew <andrew.kaylor at intel.com>
Cc: cfe-dev at lists.llvm.org; LLVM Developers Mailing List <llvm-dev at
lists.llvm.org>; Ristow, Warren <warren.ristow at sony.com>; Ulrich
Weigand (Ulrich.Weigand at de.ibm.com) <Ulrich.Weigand at de.ibm.com>;
Cameron McInally <cameron.mcinally at nyu.edu>; Kevin Neal <Kevin.Neal
at sas.com>; Blower, Melanie I <melanie.blower at intel.com>; hfinkel
at anl.gov; Sanjay Patel <spatel at rotateright.com>; Wang, Pengfei
<pengfei.wang at intel.com>
Subject: Re: Floating point semantic modes

STDC FENV_ACCESS {ON|OFF}
  Patch in progress. I think ON should force the following:

    except_behavior { strict }
    fenv_access { on }
    rounding_mode { dynamic }
    denormal_fp_math { IEEE }
    denormal_fp32_math { IEEE }
    no_signed_zeros { off }
    allow_reciprocal { off }
    allow_approximate_fns { off }
    allow_reassociation { off }

The pragma `STDC FENV_ACCESS` notifies compiler about access to FP environment,
so `except_behavior`, `fenv_access` and `rounding_mode` should be set according
to this list. But other properties should not be set by this pragma unless they
are required by some of these. `allow_reassociation { off }` look like required
for ` except_behavior { strict }`. What prevents us from using `no_signed_zeros
{ on }` together with the pragma  `STDC FENV_ACCESS`?

Thanks,
--Serge


On Tue, Jan 28, 2020 at 6:24 AM Kaylor, Andrew <andrew.kaylor at
intel.com<mailto:andrew.kaylor at intel.com>> wrote:
Hi all,

I’m trying to put together a set of rules for how the various floating point
semantic modes should be handled in clang. A lot of this information will be
relevant to other front ends, but the details are necessarily bound to a front
end implementation so I’m framing the discussion here in terms of clang. Other
front ends can choose to follow clang or not. The existence of this set of
semantics is an LLVM property that applies to all front ends, but the front ends
will have to do something to initialize them.

I will eventually do something to convert this into an RST document and find a
home for it in the clang documentation, but I’d like to start by getting input
on whether everyone agrees with my judgment on how these things should work and
whether I’ve missed anything.

Here’s what I’ve got.

=====================FP semantic modes
=====================except_behavior { ignore, strict, may_trap }
fenv_access { on, off }
rounding_mode { dynamic, tonearest, downward, upward, towardzero }
contract { on, off, fast }
denormal_fp_math { IEEE, PreserveSign, PositiveZero }
denormal_fp32_math { IEEE, PreserveSign, PositiveZero }
support_math_errno { on, off }
no_honor_nans { on, off }
no_honor_infinities { on, off }
no_signed_zeros { on, off }
allow_reciprocal { on, off }
allow_approximate_fns { on, off }
allow_reassociation { on, off }

---------------------
Dependencies
---------------------
rounding_mode must be "tonearest" if fenv_access is "off" --
It is the user's responsibility to make sure the dynamic rounding mode is
not left in another state.

if except_behavior is not "ignore", allow_reciprocal,
allow_approximate_fns and allow_reassociation must be "off".

=====================FP models
=====================-----------------------
precise (default)
-----------------------
except_behavior { ignore }
fenv_access { off }
rounding_mode { tonearest }
contract { on }
denormal_fp_math { IEEE }
denormal_fp32_math { IEEE }
support_math_errno { on }
no_honor_nans { off }
no_honor_infinities { off }
no_signed_zeros { off }
allow_reciprocal { off }
allow_approximate_fns { off }
allow_reassociation { off }

------------------
strict
------------------
except_behavior { strict }
fenv_access { on }
rounding_mode { dynamic }
contract { off }
denormal_fp_math { IEEE }
denormal_fp32_math { IEEE }
support_math_errno { on }
no_honor_nans { off }
no_honor_infinities { off }
no_signed_zeros { off }
allow_reciprocal { off }
allow_approximate_fns { off }
allow_reassociation { off }

------------------
fast
------------------
except_behavior { ignore }
fenv_access { off }
rounding_mode { tonearest }
contract { fast }
denormal_fp_math { PreserveSign }
denormal_fp32_math { PreserveSign }
support_math_errno { off }
no_honor_nans { on }
no_honor_infinities { on }
no_signed_zeros { on }
allow_reciprocal { on }
allow_approximate_fns { on }
allow_reassociation { on }

=====================Command-line options
=====================-ffp-model={precise|strict|fast}
  Sets all semantic modes as described above.

-ffast-math
  Equivalent to -ffp-model=fast. (I'm not sure that's currently true.)

-f[no-]math-errno
-ffp-contract={on|off|fast}
-f[no-]honor-infinities
-f[no-]honor-nans
-f[no-]associative-math
-f[no-]reciprocal-math
-f[no-]signed-zeros
-f[no-]trapping-math
-f[no-]rounding-math
-fdenormal-fp-math={ieee, preservesign, positivezero}
-fdenormal-fp-math-fp32={ieee, preservesign, positivezero}
-ffp-exception-behavior={ignore,maytrap,strict}
  Each of these has a 1-to-1 correspondance to an FP semantic mode.
  (I think several of these should set "except_behavior" to
"ignore".)


-f[no-]finite-math-only
  Controls no_honor_nans and no_honor_infinities.

-f[no-]unsafe-math-optimizations
  Turns no_signed_zeros, allow_reciprocal, allow_approximate_fns, and
allow_reassociation on or off.
  Also, sets except_behavior to "on" for -funsafe-math-optimizations.
  (Currently, -fno-]unsafe-math-optimizations clears except_behavior, but I
regard this as a bug.)

All command line options will override any previous values of all settings they
control with options taking effect in a left-to-right manner.

=====================pragmas
=====================STDC FENV_ACCESS {ON|OFF}
  Patch in progress. I think ON should force the following:

    except_behavior { strict }
    fenv_access { on }
    rounding_mode { dynamic }
    denormal_fp_math { IEEE }
    denormal_fp32_math { IEEE }
    no_signed_zeros { off }
    allow_reciprocal { off }
    allow_approximate_fns { off }
    allow_reassociation { off }

  And OFF should set fenv_access to off, except_behavior to ignore, and
rounding_mode to tonearest. Other modes should be reset to their command line
defined settings.

  I don't think this pragma should have any effect on contract,
support_math_errno, no_honor_nans, or no_honor_infinities.

STDC FP_CONTRACT {ON|OFF|DEFAULT}
  This pragma controls the contract FP semantic mode. No other FP semantic modes
are effected.

float_control ({precise|except}, {on|off}[, push])
float_control (pop)
  Patch in progress. These are tricky.
  I think they should have the following effects:

float_control (precise, on[, push])
  contract { on }
  denormal_fp_math { IEEE }
  denormal_fp32_math { IEEE }
  no_signed_zeros { off }
  allow_reciprocal { off }
  allow_approximate_fns { off }
  allow_reassociation { off }

float_control (precise, off[, push])
  contract { fast }
  denormal_fp_math { preservesign }
  denormal_fp32_math { preservesign }
  no_signed_zeros { on }
  allow_reciprocal { on }
  allow_approximate_fns { on }
  allow_reassociation { on }

Note, this is less than what the -ffp-model=precise control does. Should this
override support_math_errno, no_honor_nans, or no_honor_infinities?

float_control (except, on[, push])
  except_behavior { strict }

float_control (except, off[, push])
  except_behavior { ignore }

The MSVC documentation says you can only use the float_control pragma to turn
exception semantics on when precise semantics are enabled. For us, this would
mean:
  denormal_fp_math { IEEE }
  denormal_fp32_math { IEEE }
  no_signed_zeros { off }
  allow_reciprocal { off }
  allow_approximate_fns { off }
  allow_reassociation { off }

The MSVC documentation also says you can't use the float_control pragma to
turn excpetion semantics off when precise semantics are enabled, and you
can't use the float_control pragma to turn precise off when fenv_access is
on.

I believe we should follow the MSVC restrictions.

========================Code-visible identifiers
========================__FAST_MATH__

This symbol will only be defined if and only if all of the following are set
(before pragmas are applied):
  except_behavior { ignore }
  fenv_access { off }
  rounding_mode { tonearest }
  contract { fast }
  denormal_fp_math { PreserveSign }
  denormal_fp32_math { PreserveSign }
  support_math_errno { off }
  no_honor_nans { on }
  no_honor_infinities { on }
  no_signed_zeros { on }
  allow_reciprocal { on }
  allow_approximate_fns { on }
  allow_reassociation { on }

__FINITE_MATH_ONLY__

This symbol will only be defined if and only if all of the following are set
(before pragmas are applied):
  no_honor_nans { on }
  no_honor_infinities { on }

FLT_ROUNDS

Should be set to -1 (indeterminable) if rounding_mode() is dynamic or 1
(tonearest) if rounding_mode is tonearest. There are values for other rounding
modes, but clang offers no way to set those rounding modes.

FLT_EVAL_METHOD

Should be set to -1 if any of allow_reciprocal, allow_approximate_fns, or
allow_reassociation is set. Should any other flags also make this -1? Otherwise,
the setting is target-defined.

math_errhandling

The MATH_ERRNO bit will be set or cleared based on the setting of
support_math_errno. Should MATH_ERREXCEPT be set or cleared based on
except_behavior?


Thanks in advance for any opinions and suggestions.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200129/0393a4d5/attachment.html>

On Wed, Jan 29, 2020 at 1:51 PM Kaylor, Andrew <andrew.kaylor at
intel.com> wrote:
>
> Yes, you’re probably right about this. I was originally thinking of
FENV_ACCESS as a fully strict mode of operation, but what you’re suggesting
aligns with what Cameron suggested and even some of my own reasoning on other
points. So, let me amend my previous proposal to say:
>
>
>
> STDC FENV_ACCESS {ON|OFF}
>   Patch in progress. I think ON should force the following:
>
>     except_behavior { strict }
>     fenv_access { on }
>     rounding_mode { dynamic }
>   Other modes should be unchanged.
Does that apply to -ffp-model=strict too?

If FMFs are really orthogonal to -ffp-model=, then we shouldn't be
setting default values for the FMFs.
>------------------
>
>strict
>
>------------------
>
>except_behavior { strict }
>fenv_access { on }
>rounding_mode { dynamic }
>contract { off }
>denormal_fp_math { IEEE }
>denormal_fp32_math { IEEE }
>support_math_errno { on }
>no_honor_nans { off }
>no_honor_infinities { off }
>no_signed_zeros { off }
>allow_reciprocal { off }
>allow_approximate_fns { off }
>allow_reassociation { off }

No, the fp-model options are intentionally umbrella/convenience options that set
everything. So, -fp-model=strict is intended to provide exactly the "fully
strict" mode that I was incorrectly associating with FENV_ACCESS. That is,
the FMFs are orthogonal to fenv_access, but no fp modes are orthogonal to
fp-model.

You can, of course, override individual settings from the fp-model. For
instance, "-fp-model=strict -fassociative-math" could be allowed.

-----Original Message-----
From: Cameron McInally <cameron.mcinally at nyu.edu> 
Sent: Wednesday, January 29, 2020 11:57 AM
To: Kaylor, Andrew <andrew.kaylor at intel.com>
Cc: Serge Pavlov <sepavloff at gmail.com>; cfe-dev at lists.llvm.org; LLVM
Developers Mailing List <llvm-dev at lists.llvm.org>; Ristow, Warren
<warren.ristow at sony.com>; Ulrich Weigand (Ulrich.Weigand at de.ibm.com)
<Ulrich.Weigand at de.ibm.com>; Kevin Neal <Kevin.Neal at sas.com>;
Blower, Melanie I <melanie.blower at intel.com>; hfinkel at anl.gov;
Sanjay Patel <spatel at rotateright.com>; Wang, Pengfei <pengfei.wang
at intel.com>
Subject: Re: Floating point semantic modes

On Wed, Jan 29, 2020 at 1:51 PM Kaylor, Andrew <andrew.kaylor at
intel.com> wrote:
>
> Yes, you’re probably right about this. I was originally thinking of
FENV_ACCESS as a fully strict mode of operation, but what you’re suggesting
aligns with what Cameron suggested and even some of my own reasoning on other
points. So, let me amend my previous proposal to say:
>
>
>
> STDC FENV_ACCESS {ON|OFF}
>   Patch in progress. I think ON should force the following:
>
>     except_behavior { strict }
>     fenv_access { on }
>     rounding_mode { dynamic }
>   Other modes should be unchanged.
Does that apply to -ffp-model=strict too?

If FMFs are really orthogonal to -ffp-model=, then we shouldn't be setting
default values for the FMFs.
>------------------
>
>strict
>
>------------------
>
>except_behavior { strict }
>fenv_access { on }
>rounding_mode { dynamic }
>contract { off }
>denormal_fp_math { IEEE }
>denormal_fp32_math { IEEE }
>support_math_errno { on }
>no_honor_nans { off }
>no_honor_infinities { off }
>no_signed_zeros { off }
>allow_reciprocal { off }
>allow_approximate_fns { off }
>allow_reassociation { off }