[PATCH] D142907: LangRef: Add "dynamic" option to "denormal-fp-math"

Matt Arsenault via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Feb 17 14:05:29 PST 2023


arsenm added inline comments.


================
Comment at: llvm/docs/LangRef.rst:2166
+
+    If the mode is ``"dynamic"``, the behavior is derived from the
+    dynamic state of the floating-point environment. Transformations
----------------
pengfei wrote:
> 1. Does it mean users must specify `dynamic` when they change FTZ/DAZ in a function?
> 2. If 1) is true, is there a way to partially set on functions in its call stack, e.g.,
> ```
> main
>   f0
>   f1
>     f10
>       setFtzDaz(true);
>   f2
>   f3
> ```
> Ideally, users may want to tell compiler `main`, `f1`, `f10` is `dynamic`, while `f0` is `ieee` and `f2`, `f3` is `positive-zero`, rather than `dynamic` for all.
> 3. If 2) is true, it looks silly to do it one by one manually. Should compiler help to deduce this information itself?
This is really a question of how strictfp should interact with the default mode and shouldn't be a different policy from how strictfp functions treat the rounding mode. Arbitrary strictfp functions don't make assumptions based on the default rounding mode, assuming it's not the default. In that sense, denormal-fp-mode doesn't really matter for strictfp functions. They just can't make use of it to optimize. If we had a denormal annotation like the rounding mode, we could make use of it in the same way 

This isn't an area for the backend to deduce, semantic meaning needs to be specific and explicit. I have no interest in making changing the denormal mode simple or easy. Turning on flushing isn't really semantically desirable and is basically obsolete on modern hardware.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D142907/new/

https://reviews.llvm.org/D142907



More information about the cfe-commits mailing list