On Monday, 6 September 2021 14:40:31 CEST Richard Biener wrote: > I'll note that currently a + PAREN_EXPR (b * c) is for example > also not contracted to PAREN_EXPR (FMA (PAREN_EXPR (a), b, c)) > even though technically FP contraction is not association. But > that's an implementation detail that could be changed. There > are likely other transforms that it prevents as well that are > not assocations, the implementation focus was correctness > as to preventing association, not so much not hindering > unrelated optimizations. If you run into any such issues > reporting a bugzilla would be welcome.
Thanks, interesting point. I believe it might even be useful to nail down that behavior (i.e. document it and write a test). Because a + b * c evaluates b * c before the addition in any case. So why would anyone add a PAREN_EXPR around b * c? We have (std::)fma (__builtin_fma) to explicitly request contraction. PAREN_EXPR seems like a good fit to inhibit contraction. -- ────────────────────────────────────────────────────────────────────────── Dr. Matthias Kretz https://mattkretz.github.io GSI Helmholtz Centre for Heavy Ion Research https://gsi.de stdₓ::simd ──────────────────────────────────────────────────────────────────────────
