Page MenuHomePhabricator

[SLC] Allow llvm.pow(x,2.0) -> x*x etc even if no pow() lib func
Needs ReviewPublic

Authored by tpr on Mon, Sep 30, 9:32 AM.

Details

Summary

Previously, SLC was disallowing those optimizations if TLI said there is
no pow() library function.

Change-Id: I01c461df3537760b4919422b5ad3a2f004eb4f0f

Diff Detail

Event Timeline

tpr created this revision.Mon, Sep 30, 9:32 AM
Herald added a project: Restricted Project. · View Herald TranscriptMon, Sep 30, 9:32 AM
tpr added a subscriber: foad.Mon, Sep 30, 11:05 AM

@foad pointed out that this fix is wrong. TLI saying pow() is not supported means if we find a call to a function called pow() then we don't know its semantics. So I will push a revised fix.

tpr updated this revision to Diff 222468.Mon, Sep 30, 11:42 AM

V2: Better fix that does not accidentally allow pow() transforms.

I don't understand what the check is supposed to be doing in the first place. If we're in LibCallSimplifier::optimizePow, we've already checked that the call is actually calling a function with the right semantics, not just the name.

Indeed, it seemed to be a coarse check in case the following transformations end up calling pow(). However, the only transformation that calls pow() is when shrinking to powf(), which itself chacks for the availability of this routine. So this patch seems to address this issue the wrong way. It seems that removing this check would be better.

evandro added inline comments.Mon, Oct 7, 3:21 PM
test/Transforms/InstCombine/pow-1.ll
120

I don't see a good reason why this check was removed.