I rebased https://reviews.llvm.org/D69272 to work on the blocking comment from @rsmith
@sepavloff Is it OK if I continue work on this item? Not sure about the protocol when continuing someone else's patch.
@rsmith asked "I don't see changes to the constant evaluator". The semantic rules for enabling this pragma require that strict or precise semantics be in effect., see SemaAttr.cpp And the floating point constant evaluation doesn't occur when strict or precise
One of the test cases in this patch shows 1+2 isn't folded in strict mode.
However, I don't see where is the decision about floating point constant folding, can someone tell me where that occurs? . I thought the constant folding was in AST/ExprConstant.cpp and indeed constant folding does occur there. But sometimes, if the floating point semantics are set to 'strict', even tho' folding has occurred successfully in ExprConstant.cpp, when i look at emit-llvm, there is arithmetic emitted for the floating point expression; For example if you use the command line option -ffp-exception-behavior=strict and you compile this function, it will emit the add instruction; but without the option you will see the folded expression 3.0. Either way (i.e. regardless of option) if you put a breakpoint inside ExprConstant.cpp the calculation of the floating sum does occur. The function is float myAdd(void) { return 1.0 + 2.0; }
I don't think this deduction is correct.
AllowFEnvAccess implies that user can access FP environment in a way unknown to the compiler, for example by calling external functions or by using inline assembler. So if AllowFEnvAccess is set, the compiler must assume that rounding mode is dynamic, as user can set it to any value unknown to the compiler. Similarly, FPExceptionMode must be set to strict as user may read/write exception bits in any way or may associate them with traps. These deductions are valid and compiler must apply them.
The reverse is not valid. AllowFEnvAccess is a very coarse instrument to manipulate FP environment, it prevents from many optimization techniques. In contrast, setting RoundingMode to dynamic means only that rounding mode may be different from the default value. If a user changes rounding mode by calls to external functions like fesetmode or by using some intrinsic, the compiler still can, for example, reorder FP operations, if FPExceptionMode is ignore. Impact of performance in this case can be minimized.