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

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

In D142907#4132836 <https://reviews.llvm.org/D142907#4132836>, @jcranmer-intel wrote:

> 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)

I think this is not really useful for strictfp. We could make use of this if we were to inline non-strictfp functions into strictfp functions if we had a denormal mode annotation on the constrained intrinsic, which we don't. Without that, strictfp functions can't make assumptions based on the default rounding mode so this doesn't inform anything useful in the presence of a changeable mode


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

https://reviews.llvm.org/D142907