[PATCH] D74713: [ConstantFold] fold most FP ops with undef operand to undef rather than NaN

[Sanjay Patel via Phabricator via llvm-commits]

spatel added a comment.

In D74713#1879563 <https://reviews.llvm.org/D74713#1879563>, @efriedma wrote:

> > Is that enough to say the result is undef?
>
> Theoretically, no.  To take a simple integer example, suppose you have "max(undef, 1)".  You can toggle any of the bits separately, but you can't produce 0, so converting it to "undef" is wrong.  Alive2 does these sorts of proofs if you want mechanical verification (although I don't think it handles fp).
>
> Practically, I doubt anyone would notice if "1e100+undef" produced an impossible result.


That's what I was expecting: each FP opcode has exact bit patterns that can never be created given one known constant operand. However, we do not have the FP analysis to determine those patterns in LLVM currently, and even if we did, there's no practical way to use that knowledge for optimization.

Having these fold to undef would make things like D73978 <https://reviews.llvm.org/D73978> and vector demanded elements easier, but if the consensus is to keep things theoretically pure, we'll have to work around the NaN folding.


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

https://reviews.llvm.org/D74713