[PATCH] D99675: RFC [llvm][clang] Create new intrinsic llvm.arith.fence to control FP optimization at expression level

Thu Apr 8 10:57:22 PDT 2021

efriedma added a comment.

In D99675#2672138 <https://reviews.llvm.org/D99675#2672138>, @kbsmith1 wrote:

> In D99675#2671924 <https://reviews.llvm.org/D99675#2671924>, @efriedma wrote:
>
>> How is llvm.arith.fence() different from using "freeze" on a floating-point value?  The goal isn't really the same, sure, but the effects seem similar at first glance.
>
> They are similar.  However, freeze is a no-op if the operand can be proven not to be undef or poison, and in such circumstances could be removed by an optimizer.  llvm.arith.fence cannot be removed by an optimizer, because doing so might allow instructions that were "outside" the fence from being reassociated/distrbuted with the instructions/operands that were inside the fence.

Okay.  In practice, it's basically impossible for us to prove that the result of "fast" arithmetic isn't poison, given the way ninf/nnan are defined, but depending on that would be fragile.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99675