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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
