[llvm] LICM: hoist BO assoc for FAdd and FMul (PR #108415)

[Joshua Cranmer via llvm-commits]

jcranmer-intel wrote:

> Is it OK to reassociate `(A +ninf,reassoc B) +ninf,reassoc C` to `A +ninf,reassoc (B +ninf,reassoc C)`? The reassociation might introduce an infinity in the intermediate result B+C where there was none before, which the ninf will turn into poison.

`ninf` effectively combines two separate assertions: that its input operands are not infinite, and that its operation does not overflow. The first assertion is trivially preserved by the rewrite. The second assertion is not necessarily preserved by the transformation due to the particulars of overflow.

On the other hand: we have some flexibility to define the meaning of `reassoc`, and its interaction with `nnan`, `ninf`, and `nsz` flags. It's trickier to define appropriate formal semantics, but from a user intent perspective, if they were worried about reassociation causing an overflow to happen that their code originally intentionally avoided, then they wouldn't have told the optimizer it was safe to reassociate! In that vein, it's reasonable to have the basic reassociation transform simply do the intersection of fast-math flags on the two operations, including the poison-based flags.

As a side note: `nsz` isn't intrinsically required as a prerequisite for reassociation, that `isAssociative` checks it is only a temporary situation (see https://reviews.llvm.org/D47335, although there be nothing so permanent as a temporary fix).

https://github.com/llvm/llvm-project/pull/108415