[PATCH] D53370: Add a emitUnaryFloatFnCall version that fetches the function name from TLI

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 17 12:24:38 PDT 2018


efriedma accepted this revision.
efriedma added a comment.
This revision is now accepted and ready to land.

LGTM.

It looks like you didn't touch LibCallSimplifier::optimizeLog, but I guess that's not necessary (it probably shouldn't be using emitUnaryFloatFnCall anyway).



================
Comment at: lib/Transforms/Utils/SimplifyLibCalls.cpp:1081-1082
   else
     R = isBinary ? emitBinaryFloatFnCall(V[0], V[1], CalleeNm, B, CalleeAt)
                  : emitUnaryFloatFnCall(V[0], CalleeNm, B, CalleeAt);
 
----------------
uabelho wrote:
> I don't know if these calls pose any problem? Since we use the name of the function that we already called I suppose we at least shouldn't end up with a name like ""?
> 
> Also since we can deal with many different kinds of lib functions here I'm not sure how messy it is to find the double/float/long double versions of the function and use the new interface?
> 
> Suggestions?
In theory it's possible to run into a similar problem: the float version might not exist, or might not have the expected name.  We should be using the LibFunc enum, rather than appending "f" to the name.  And it's probably not that hard to fix; all the callers of optimizeBinaryDoubleFP and optimizeUnaryDoubleFP know exactly what function they're optimizing.

That said, all the callers of optimizeDoubleFP call hasFloatVersion(), which I think prevents any practical problems.


Repository:
  rL LLVM

https://reviews.llvm.org/D53370





More information about the llvm-commits mailing list