[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#1632642 <https://reviews.llvm.org/D66092#1632642>, @sepavloff wrote:

> - What is the issue with moving `a = b/c`? If it moves ahead of `if` statement it seems OK, because the rounding mode is the same in that point. It cannot be moved inside the block (where rounding mode is different) because it breaks semantics.


It may be that the optimizer can prove that 'someCondition' is always true and it will eliminate the if statement and there is nothing to prevent the operation from migrating between the calls that change the rounding mode.

This is my main point -- "call i32 @fesetround" does not act as a barrier to an fdiv instruction (for example), but it does act as a barrier to a constrained FP intrinsic. It is not acceptable, for performance reasons in the general case, to have calls act as barriers to unconstrained FP operations. Therefore, to keep everything semantically correct, it is necessary to use constrained intrinsics in any function where the floating point environment may be changed.

I agree that impact on performance must be minimized, but this is necessary for correctness.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66092