[llvm-dev] Floating point semantic modes

[Cameron McInally via llvm-dev]

On Mon, Jan 27, 2020 at 6:24 PM Kaylor, Andrew <andrew.kaylor at intel.com> wrote:
...
> ======================
>
> 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 }

I misunderstood the purpose of -ffp-model=fast. I assumed that was a
*trap-safe mode* where we care more about performance than strict
IEEE-754 conformance. I.e., I would like a mode where *hard*
trap-unsafe optimizations (e.g. hoisting) are disabled, but *soft*
trap-unsafe optimizations (e.g. reassociation, optimized math libs)
are performed. The thinking is that Invalid, DivisionByZero, and
Overflow are the most important traps, but I'm willing to give up some
edge cases around Overflow.

I suppose that having orthogonal FMFs is a good start, but that would
require updating Reassociate et al. to handle the constrained
intrinsics. From my off-line discussion with Andy, it doesn't sound
like that was a consideration.

Would anyone else like to see a heavily optimized (risky) trap-safe
mode like this?