This is an archive of the discontinued LLVM Phabricator instance.

Fold fmin(nnan x, inf) -> x, fmax(nnan x, -inf) -> x, fmax(nnan ninf x, -flt_max) -> x and fmin(nnan ninf x, flt_max) -> x
Needs ReviewPublic

Authored by karthikthecool on Jun 13 2016, 6:03 AM.

Details

Reviewers
majnemer
arsenm
Summary

Hi,
Implement few TODO's in InstCombineCalls.

This patch enables folding the following instructions-
fmin(nnan x, inf) -> x
fmax(nnan x, -inf) -> x

&

fmax(nnan ninf x, -flt_max) -> x
fmin(nnan ninf x, flt_max) -> x

Thanks
Karthik Bhat

Diff Detail

Event Timeline

karthikthecool retitled this revision from to Fold fmin(nnan x, inf) -> x, fmax(nnan x, -inf) -> x, fmax(nnan ninf x, -flt_max) -> x and fmin(nnan ninf x, flt_max) -> x.
karthikthecool updated this object.
karthikthecool added reviewers: arsenm, majnemer.
karthikthecool set the repository for this revision to rL LLVM.
karthikthecool added a subscriber: llvm-commits.
davide added a subscriber: davide.Jun 19 2016, 1:17 PM
davide added inline comments.
lib/Transforms/InstCombine/InstCombineCalls.cpp
1007–1014

You should be able to put these where // fmin(x, -inf) -> -inf is performed, so that you avoid duplicating the check C1 && C1->isInfinity().

escha added a subscriber: escha.Jun 19 2016, 4:22 PM

Is this correct? I thought "nnan" on an instruction meant that we can optimize it assuming its inputs and outputs aren't NaN -- not that we can assume *for other instructions, that aren't fast-math* that *their inputs* aren't NaN.

So for example:

float foo(float x, float y) {
float z = x +nnan y; // pseudocode for a nnan add
return fmax(z, 1.0);
}

This optimization makes it legal for this function to return NaN even though fmax isn't fast-math. I don't think (from a quick grep) that we treat nnan or the other fast-math flags in this way anywhere else in LLVM. That is, if op A is not fast-math, and op B is fast-math, and op B is an argument to op A, it feels very odd to be able to optimize op A in a fast-math fashion using this knowledge.

More practically, I think this may actually break our existing use-case: we use fmax/fmin to implement NaN-flushing behavior in shaders, i.e. we allow users to use fmax/fmin/clamp to get rid of NaNs even though fast-math is on in other respects. If we allow this NaN-flushing behavior to be violated, fmax/fmin will no longer do what we need.

arsenm resigned from this revision.Feb 21 2019, 6:23 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 21 2019, 6:23 PM
Herald added a subscriber: wdng. · View Herald Transcript