On Mon, 6 Sep 2021, Matthias Kretz wrote: > 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?
At least for integers we have transforms that do a + a * c -> a * (1 + c) so one could think of (x/y) + (x/y)*c -> (x/y) * (1 + c) which would then have associated the c * (x/y) multiplication ... Or when c is constant then a + a * C can be simplified. > We have (std::)fma (__builtin_fma) to explicitly request contraction. > PAREN_EXPR seems like a good fit to inhibit contraction. OK, I guess it should apply to PAREN_EXPR (a + a) + a as well which then does not become 3 * PAREN_EXPR (a). Likewise PAREN_EXPR (a) - a might eventually not become zero (I'm not absolutely sure about that ;)) Richard.
