[PATCH] D53157: Teach the IRBuilder about constrained fadd and friends

[Cameron McInally via Phabricator via cfe-commits]

cameron.mcinally added a comment.

Fair enough. Just for conversation's sake, I was envisioning the FE support a little differently...

1. Add a command line option, say `-ffpe_safe=[true|false]`, that toggles FPEnv-safe code generation for a whole file. A `-ffpe_safe=true` would be equivalent to `FENV_ACCESS=ON` at the beginning of a translation unit and we would capture it in some FE variable. That command line option can be overridden by the FENV_ACCESS pragma.

2. If the FENV_ACCESS pragma is seen, carry a nop/metadata/something construct to toggle the FE variable during IR generation.

3. Then when generating IR, choose between constrained/unconstrained IR depending on the state of the FE variable.

#1 may seem superfluous, but there are certain benchmarks (e.g. SPEC CPU) that do not allow for code modifications. So, in order to run those with FPEnv-safe code, we'd need a non-invasive way to toggle FPEnv-safe code generation.

I'll also add that my interpretation of FENV_ACCESS in the C Standard [7.6.1] implies that we have to track the FENV_ACCESS pragma. That is, it's not okay to ignore FENV_ACCESS=OFF. When we transfer from FENV_ACCESS=OFF code to FENV_ACCESS=ON code, the rounding mode needs to be reset to the default setting. But, I'm open to hearing other interpretations. My copy of the Standard is old, so please correct me if this changed...

  When execution passes from a part of the program translated with FENV_ACCESS ‘‘off’’ to a part translated with FENV_ACCESS ‘‘on’’, the state of the floating-point status flags is unspecified and the floating-point control modes have their default settings.


https://reviews.llvm.org/D53157