Previously, SLC was disallowing those optimizations if TLI said there is
no pow() library function.
foad on Sep 30 2019, 9:32 AM.Authored by
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.
The patch description is only stating the previous status-quo as a fact,
Is this really sane?
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.