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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
