[PATCH] D66092: [CodeGen] Generate constrained fp intrinsics depending on FPOptions

[Andy Kaylor via Phabricator via cfe-commits]

andrew.w.kaylor added a comment.

In D66092#1627339 <https://reviews.llvm.org/D66092#1627339>, @sepavloff wrote:

> In D66092#1625380 <https://reviews.llvm.org/D66092#1625380>, @kpn wrote:
>
> > Also, if any constrained intrinsics are used in a function then the entire function needs to be constrained. Is this handled anywhere?
>
>
> If we decided to make the entire function constrained, it should be done somewhere in IR transformations, because inlining may mix function bodies with different fp options.


Kevin is right. We have decided that if constrained intrinsics are used anywhere in a function they must be used throughout the function. Otherwise, there would be nothing to prevent the non-constrained FP operations from migrating across constrained operations and the handling could get botched. The "relaxed" arguments ("round.tonearest" and "fpexcept.ignore") should be used where the default settings would apply. The front end should also be setting the "strictfp" attribute on calls within a constrained scope and, I think, functions that contain constrained intrinsics.

We will need to teach the inliner to enforce this rule if it isn't already doing so, but if things aren't correct coming out of the front end an incorrect optimization could already happen before we get to the inliner. We always rely on the front end producing IR with fully correct semantics.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66092