This is an archive of the discontinued LLVM Phabricator instance.

Handle sqrt() shrinking in SimplifyLibCalls like any other call
ClosedPublic

Authored by spatel on Oct 22 2014, 2:06 PM.

Details

Summary

This patch removes a chunk of special case logic for folding sqrt() -> sqrtf() in InstCombineCasts and handles it in the mainstream path of SimplifyLibCalls.

No functional change intended, but I loosened the restriction on the existing sqrt testcases to allow for this optimization even without unsafe-fp-math because that's the existing behavior.

I also added a missing test case for not shrinking the llvm.sqrt.f64 intrinsic in case the result is used as a double.

Diff Detail

Event Timeline

spatel updated this revision to Diff 15278.Oct 22 2014, 2:06 PM
spatel retitled this revision from to Handle sqrt() shrinking in SimplifyLibCalls like any other call.
spatel updated this object.
spatel edited the test plan for this revision. (Show Details)
spatel added reviewers: hfinkel, beanz.
spatel added a subscriber: Unknown Object (MLST).
hfinkel edited edge metadata.Oct 23 2014, 11:01 AM

No functional change intended, but I loosened the restriction on the existing sqrt testcases to allow for this optimization even without unsafe-fp-math because that's the existing behavior.

Please don't loosen this for the function call (although leave it as-is for the intrinsic). The intrinsic is different here, especially because it is defined to have different semantics than the function call, but we should not change the function call itself without fast-math enabled. The underlying issue is that (float) sqrt(x) != sqrtf(x) in general because of rounding issues (and on some systems, the sqrtf is not exactly 1ulp accurate), and we should not alter that without fast-math enabled.

In D5919#4, @hfinkel wrote:

Please don't loosen this for the function call (although leave it as-is for the intrinsic). The intrinsic is different here, especially because it is defined to have different semantics than the function call, but we should not change the function call itself without fast-math enabled. The underlying issue is that (float) sqrt(x) != sqrtf(x) in general because of rounding issues (and on some systems, the sqrtf is not exactly 1ulp accurate), and we should not alter that without fast-math enabled.

Let me make sure we're on the same page. The existing behavior is to transform this function call:

float x;
float y = (float) sqrt ((double) x)

or in IR:

%conv = fpext float %f to double
%call = call double @sqrt(double %conv)
%conv1 = fptrunc double %call to float
ret float %conv1

into:

float y = sqrtf (x);

There's are 2 existing positive test cases in test/Transform/InstCombine/sqrt.ll that check for this pattern and 1 negative test case to make sure we don't optimize in the event the result is used as a double.

Are you saying those existing test cases are invalid? I think that the sqrt function call test that I'm proposing to modify in double-float-shrink-1.ll would actually become redundant with the second test case in sqrt.ll; that was added for:
http://llvm.org/bugs/show_bug.cgi?id=8096

hfinkel accepted this revision.Oct 23 2014, 12:59 PM
hfinkel edited edge metadata.
This revision is now accepted and ready to land.Oct 23 2014, 12:59 PM
spatel closed this revision.Oct 23 2014, 3:03 PM
spatel updated this revision to Diff 15352.

Closed by commit rL220514 (authored by @spatel).