Blower, Melanie I via llvm-dev
2020-Jan-28 19:24 UTC
[llvm-dev] Floating point semantic modes
About ftrapping-math:
I think we should eliminate ftrapping-math, a boolean option, because it
overlaps with ffp-exception-behavior, a 3 valued option. Or we can keep it in
the clang driver for compatibility, but it should be rewritten by clang driver
into ffp-exception-behavior=ignore and ffp-exception-behavior=strict. There are
various fields in llvm and/or clang that maintain Boolean TrappingMath, those
should be removed/rewritten.
About ffp-contract:
Currently the clang driver, at default setting, doesn't specify a value for
ffp-contract, nothing is passed through to llvm in LangOpts or CodegenOpts,
digging around in llvm I find that the default setting in llvm is
"Standard"==on just like you said. Shall we change clang to always
pass through the option values rather than relying on llvm default? To me it
seems more secure to have all settings exactly specified.
static cl::opt<llvm::FPOpFusion::FPOpFusionMode> FuseFPOps(
"fp-contract", cl::desc("Enable aggressive formation of fused
FP ops"),
cl::init(FPOpFusion::Standard),
cl::values(
clEnumValN(FPOpFusion::Fast, "fast", "Fuse FP ops
whenever profitable"),
clEnumValN(FPOpFusion::Standard, "on", "Only fuse
'blessed' FP ops."),
clEnumValN(FPOpFusion::Strict, "off",
"Only fuse FP ops when the result won't be
affected.")));
About math-errno:
There are comments in the clang code that describe the settings for math-errno
as toolchain dependent. Here's the initialization:
// -fmath-errno is the default on some platforms, e.g. BSD-derived OSes.
bool MathErrno = TC.IsMathErrnoDefault();
Here's another comment,
// Turning *off* -ffast-math restores the toolchain default.
MathErrno = TC.IsMathErrnoDefault();
> -----Original Message-----
> From: Szabolcs Nagy <nsz at port70.net>
> Sent: Tuesday, January 28, 2020 8:09 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>;
> sepavloff at gmail.com; hfinkel at anl.gov; Sanjay Patel
> <spatel at rotateright.com>; Wang, Pengfei <pengfei.wang at
intel.com>
> Subject: Re: [llvm-dev] Floating point semantic modes
>
> * Kaylor, Andrew via llvm-dev <llvm-dev at lists.llvm.org>
[2020-01-27 23:24:10
> +0000]:
> > 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.
> >
>
> i'm not an llvm/clang dev, i hope this mail wont bounce.
>
> > =====================> > 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 }
>
> note that math errno handling can be
>
> 1) errno is set,
> 2) errno may be set and
> 3) errno is guaranteed to be untouched
>
> iso c math_errhandling can select between 1 and 2, (user can or cannot rely
on
> errno) but for optimizing math calls as side-effect-free pure functions, 3
is
> needed.
>
> -f(no-)math-errno selects between 1 and 3.
> with 3, moving math calls across errno checks or calls that set errno can
break
> semantics depending on how libm is implemented (e.g. glibc will set errno
> independently of how you compiled your code).
>
> > no_honor_nans { on, off }
>
> ideally there would be a way to support snan too.
> (e.g. isnan(x) cannot be turned into x!=x then)
>
> > no_honor_infinities { on, off }
> > no_signed_zeros { on, off }
> > allow_reciprocal { on, off }
> > allow_approximate_fns { on, off }
> > allow_reassociation { on, off }
>
> excess precision handling is missing from this list which matters for x87
and
> m68k fpu support and may matter for _Float16 implementations that fall back
> to _Float32 arithmetic.
>
> the granularity of these knobs is also interesting (expression, code block,
> function or translation unit), iso c pragmas work on code block level.
>
> > =====================> > 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".)
>
> -ftrapping-math vs -ffp-exception-behaviour=maytrap is unclear.
>
> (-ftrapping-math is weird in gcc, it does not handle all fp exception
cases, not
> sure what clang plans to do with that)
>
> >
> > -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?
>
>
> FLT_ROUNDS, FLT_EVAL_METHOD and math_errhandling
>
> are controlled by the c runtime, so a compiler has no business changing
them,
> the compiler can define its own __FLT_ROUNDS, etc macros and the libc may
or
> may not use those, but e.g.
> in case of FLT_ROUNDS it makes no sense for the compiler to try to do
anything:
> the mode changes at runtime, the libc macro will expand to a function call
that
> determines the current rounding mode. (same problem arises if you can
change
> the other modes on a per function or code block granularity.)
>
> and i don't think it's a good idea to change FLT_EVAL_METHOD with
non-precise
> arithmetic modes, because it is used to decide if excess range and
precision is
> available, but arithmetic changes don't affect that. (e.g. float_t is
still same as
> float).
>
> >
> >
> > Thanks in advance for any opinions and suggestions.
> >
> > -Andy
>
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Cameron McInally via llvm-dev
2020-Jan-28 19:50 UTC
[llvm-dev] Floating point semantic modes
On Tue, Jan 28, 2020 at 2:24 PM Blower, Melanie I <melanie.blower at intel.com> wrote:> > About ftrapping-math: > I think we should eliminate ftrapping-math, a boolean option, because it overlaps with ffp-exception-behavior, a 3 valued option. Or we can keep it in the clang driver for compatibility, but it should be rewritten by clang driver into ffp-exception-behavior=ignore and ffp-exception-behavior=strict.I have a strong preference for the latter. Command-line compatibility is nice when porting makefiles from GCC.
* Blower, Melanie I <melanie.blower at intel.com> [2020-01-28 19:24:24 +0000]:> About math-errno: > There are comments in the clang code that describe the settings for math-errno as toolchain dependent. Here's the initialization: > // -fmath-errno is the default on some platforms, e.g. BSD-derived OSes. > bool MathErrno = TC.IsMathErrnoDefault();that's interesting since the bsd libm does not touch errno (at least on freebsd), so for them this creates significant overhead (e.g. when sqrt is inlined, the compiler still emits code to check the input and fall back to the libc sqrt call just in case it wants to set errno) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37073> Here's another comment, > // Turning *off* -ffast-math restores the toolchain default. > MathErrno = TC.IsMathErrnoDefault();i guess the default can be tied to the libm behaviour of the target (but ideally it will be the same everywhere so it's easier to get portable behaviour) (i personally would get rid of math errno, it causes problems, but i think the gcc/glibc position is that c89 only had errno, no fenv exceptions, so it should be supported for bw compat)
Cameron McInally via llvm-dev
2020-Jan-29 15:59 UTC
[llvm-dev] Floating point semantic modes
On Wed, Jan 29, 2020 at 6:19 AM Szabolcs Nagy <nsz at port70.net> wrote:> > * Blower, Melanie I <melanie.blower at intel.com> [2020-01-28 19:24:24 +0000]: > > About math-errno: > > There are comments in the clang code that describe the settings for math-errno as toolchain dependent. Here's the initialization: > > // -fmath-errno is the default on some platforms, e.g. BSD-derived OSes. > > bool MathErrno = TC.IsMathErrnoDefault(); > > that's interesting since the bsd libm does not touch errno > (at least on freebsd), so for them this creates significant > overhead (e.g. when sqrt is inlined, the compiler still emits > code to check the input and fall back to the libc sqrt call > just in case it wants to set errno) > > https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_bugzilla_show-5Fbug.cgi-3Fid-3D37073&d=DwIBAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=odUB_gXwu5Vt9gmHin36eUdSuDVUfd8jQqWAYPs_NzQ&s=yvN7WF-dbQSNc9Stp9v-WnlYl9B97e2G2npaJ44Eohg&e> > > Here's another comment, > > // Turning *off* -ffast-math restores the toolchain default. > > MathErrno = TC.IsMathErrnoDefault(); > > i guess the default can be tied to the libm behaviour of the > target (but ideally it will be the same everywhere so it's > easier to get portable behaviour) > > (i personally would get rid of math errno, it causes problems,Agreed. Worrying about it isn't pragmatic. And we've made it this far without proper error handling...> but i think the gcc/glibc position is that c89 only had errno, > no fenv exceptions, so it should be supported for bw compat)