[PATCH] D100118: [clang] Add support for new builtin __arithmetic_fence to control floating point optimization, and new clang option fprotect-parens

[Melanie Blower via Phabricator via cfe-commits]

mibintc added a comment.

Reply to @joerg proposing new wording for the option description



================
Comment at: clang/docs/UsersManual.rst:1484
+   Where unsafe floating point optimizations are enabled, this option
+   determines whether the optimizer honors parentheses when floating-point
+   expressions are evaluated.  If unsafe floating point optimizations are
----------------
joerg wrote:
> aaron.ballman wrote:
> > mibintc wrote:
> > > aaron.ballman wrote:
> > > > We may need to expound on what "honor parentheses" means. The summary for the patch mentions `(a + b) + c`, but does this also mean `(x + y) * z`  could be interpreted as `x + (y * z)`? What about for non-arithmetic expressions involving parentheses, like `(float1 == float2 && float1 == float3) || blah()`?
> > > Thanks for your review. Just a quick first response, What do you mean "(x + y) * z could be reinterpreted as x + (y * z)" -- not following you here? 
> > "whether the optimizer honors the parentheses" reads to me like `(x + y) * z` could either honor or not honor the parentheses, so that could either evaluate as `(x + y) * z` or `x + (y * z)` depending on whether the parens are honored or not.
> I would prefer to start with a description of the intended behavior from first principles. The logic here should not be tied to fast-mode as it also overlaps a lot with the formulation of fused multiply-add expressions and certainly should have specified behavior on the interaction. I'm also not sure about what you mean with value-safe FP modes, IIRC the C/C++ standard explicitly leave it open in which order floating point expressions of the same operand priority are evaluated.
> 
> I'm also a bit puzzled why __arithmethic_fence should not be considered a constant expression?
> I would prefer to start with a description of the intended behavior from first principles. The logic here should not be tied to fast-mode as it also overlaps a lot with the formulation of fused multiply-add expressions and certainly should have specified behavior on the interaction. I'm also not sure about what you mean with value-safe FP modes, IIRC the C/C++ standard explicitly leave it open in which order floating point expressions of the same operand priority are evaluated.

@joerg  Thank you.  What do you think about this modified description of the option:
option:: -f[no-]protect-parens:

This option pertains to floating-point types, complex types with floating-point components, and vectors of these types. Some arithmetic expression transformations that are mathematically correct and permissible according to the C and C++ language standards may be incorrect when dealing with floating-point types, such as reassociation and distribution. Further, the optimizer may ignore parentheses when computing arithmetic expressions in circumstances where the parenthesized and unparenthesized expression express the same mathematical value. For example (a+b)+c is the same mathematical value as a+(b+c), but the optimizer is free to evaluate the additions in any order regardless of the parentheses. When enabled, this option forces the optimizer to honor the order of operations with respect to parentheses in all circumstances.

Note that floating-point contraction (option `-ffp-contract=`) is disabled when `-fprotect-parens` is enabled.  Also note that in safe floating-point modes, such as `-ffp-model=precise` or `-ffp-model=strict`, this option has no effect because the optimizer is prohibited from making unsafe transformations.

> 
> I'm also a bit puzzled why __arithmethic_fence should not be considered a constant expression?
I can see your point about that. I was leery of steering into constant folding waters but I will make that change.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100118