[PATCH] D25970: DCE math library calls with a constant operand

Rong Xu via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 26 13:11:31 PDT 2016

Moving pass LibCallsShrinkWrap after loop unroll will remove all the calls
to exp() in the code shown in the bug.

Can you post the code using pow() that LibCallsShrinkWrap cannot handle?


On Tue, Oct 25, 2016 at 4:14 PM, David Li <davidxl at google.com> wrote:

> davidxl added inline comments.
> ================
> Comment at: lib/Analysis/ConstantFolding.cpp:1971
> +
> +bool llvm::isMathLibCallNoop(CallSite CS, const TargetLibraryInfo *TLI) {
> +  Function *F = CS.getCalledFunction();
> ----------------
> efriedma wrote:
> > davidxl wrote:
> > > There are lots of duplicated logic here with LibcallShinkWrap pass. I
> think the right way to do is let the later passes to clean up the dead
> calls. This can be done by pushing libcall shrinkwrap later in the pipeline.
> > The case which I originally ran into involves pow(), and
> LibCallsShrinkWrap can't really deal with that effectively, as far as I can
> tell.
> >
> > It's probably possible to refactor the logic for some of the other
> libcalls... but we want to perform the check in isInstructionTriviallyDead
> to get rid of dead calls as soon as possible, so they don't block other
> optimizations.
> Refactoring is ideal, but it may not be easy to do.  Please add a comment
> here to point to the refactoring opportunity in the future.
> Repository:
>   rL LLVM
> https://reviews.llvm.org/D25970
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161026/8ae198d2/attachment.html>

More information about the llvm-commits mailing list