[PATCH] D105895: [FPEnv][EarlyCSE] Add support for CSE of constrained FP intrinsics

[Andy Kaylor via Phabricator via llvm-commits]

andrew.w.kaylor added a comment.

In D105895#2874128 <https://reviews.llvm.org/D105895#2874128>, @kpn wrote:

> This patch may be overkill. If the reading of the floating point status register is restricted to "fpexcept.strict" then perhaps we don't need all of this code. But if we want to allow checking the status register after "fpexcept.maytrap" instructions then we do need all this. The LangRef restricts those reads to "fpexcept.strict". Are we certain we want to stick with that language?

Where does the LangRef say this?

I think reading the status register should be allowed with fpexcept.maytrap, but the results of such a test must be understood to apply only to the generated code, not the strict semantics of the source. That is, if I check the status register and see, for example, that the DIVZERO flag is set, I can be sure that something in my code caused that, but if I check the register and no exception flags are set, that might have been because code that would have caused an exception was optimized away. The "maytrap" state is intended to avoid the introduction of spurious exceptions, but it isn't guaranteed to preserve all existing exceptions.

Strictly speaking, this is an off-the-map option. The relevant standards don't let you test the FP status flag or unmask exceptions unless fenv access is enabled, which leads to the fpexcept.strict behavior. The "maytrap" mode is meant to enable some useful optimizations, like DCE of code that might contain FP exceptions, while preventing optimizations that could cause rogue FP exceptions through speculative execution.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105895