[PATCH] D41333: [ValueTracking] ignore FP signed-zero when detecting a casted-to-integer fmin/fmax pattern

[Sanjay Patel via Phabricator via llvm-commits]

spatel added a comment.

In https://reviews.llvm.org/D41333#958720, @hfinkel wrote:

> LGTM as well.
>
> Thinking about it, there are some other cases that will have a similar effect (e.g., adding/subtracting to a non-zero constant, squaring the result). Also, if the min/max is with a constant such that zero is not a possible answer. Maybe we could add a comment about that too?


Yes, there seems to be some more general opportunity to recognize FP min/max based on the surrounding uses. The more direct case with a non-zero constant is already handled via the bailout in the switch statement:

  if (!FMF.noSignedZeros() && !isKnownNonZero(CmpLHS) &&
        !isKnownNonZero(CmpRHS))

Ie, when we have a non-zero constant, that check is false, so we keep going and look for the min/max pattern.

What seems odd in that check is that's a call that only checks for a non-zero constant value. That's not the more general call to the recursive:

  static bool isKnownNonZero(const Value *V, unsigned Depth, const Query &Q);


https://reviews.llvm.org/D41333