Previously, SLC was disallowing those optimizations if TLI said there is
no pow() library function.
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.
Please update/rebase - I added a test to cover the case that I assume was intended:
|1 ↗||(On Diff #261259)|
Can you add a RUN line for this to the existing "pow-1.ll" test file instead of adding a new test file? The existing file is already used to test various target combos.
The patch description is only stating the previous status-quo as a fact,
but gives no reasoning as to why it should change, why it is legal/okay to change it.
Is this really sane?
Can we really invent calls to non-builtin (aka potentially user-provided/overriden) C math function?
How about something like: "optimizePow does not create any new calls to pow, so it should work regardless of whether the pow library function is available. This allows it to optimize the llvm.pow intrinsic on targets with no math library."
Annoyingly, if I change the commit message, arc diff doesn't propagate that to the web interface.