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

[Joshua Cranmer via Phabricator via llvm-commits]

jcranmer-intel added a comment.

In D142907#4132430 <https://reviews.llvm.org/D142907#4132430>, @arsenm wrote:

> I was thinking of changing the default in general to dynamic. I was going to at least change the strictfp default in a follow up

I had the same thought too, but I reflected a little further that the default fp model implying that the environment being in the default state means we can assume the FTZ/DAZ are also in a default (IEEE) state.

In D142907#4132543 <https://reviews.llvm.org/D142907#4132543>, @kpn wrote:

> What's the plan for tying this to strictfp? Because I don't it should be tied to cases where we use the constrained intrinsics but the exceptions are ignored and the default rounding is in stated. Those instructions are supposed to behave the same as the non-constrained instructions. So keying off the presence of the strictfp attribute on the function definition, or the (equivalent) presence of constrained intrinsics, would be too simple.

The way I see it, `strictfp` is an assertion that every FP instruction has a dependency on the FP environment, which is largely orthogonal to the `denormal-mode` attribute asserting that the FTZ/DAZ bits in the FP environment have a particular value. The constrained intrinsics also have the ability to assert some properties of the FP environment (specifically, rounding mode and exception behavior) on individual instructions. By not adding any metadata to constrained intrinsics at the same time, we don't get the ability to set the denormal-mode on a per-instruction basis-but I don't think there's much value to be gained by doing so (giving that we already have it at a per-function level).

> Would we get different denormal behavior with a clang flag vs using a #pragma at the top of a source file? That seems surprising as well.

One of the consequences of having so many different ways of controlling compiler FP environment assumptions is that there's a crazy amount of interactions to consider. But I think there is ultimately a workable solution for the clang frontend to generate interactions that make sense.


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

https://reviews.llvm.org/D142907