[llvm-dev] Floating point semantic modes
Serge Pavlov via llvm-dev
llvm-dev at lists.llvm.org
Wed Jan 29 09:33:42 PST 2020
>
> 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>
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/20200130/1e9f1a0a/attachment-0001.html>
More information about the llvm-dev
mailing list