[llvm-commits] [llvm-gcc-4.0]Patch to make llvm-gcc emit llvm.pow/sin/cos.* [for review]

Duncan Sands baldrick at free.fr
Fri Nov 23 03:57:06 PST 2007


> Another benefit I can imagine is that using llvm.pow.* will make code more
> effective than using @pow.
> As llvm began to support apfloat, and as the llvm LangRef says "You can use
> llvm.pow on any floating point or vector of floating point type. Not all
> targets support all types however", we may get chance to optimize the lR
> code by using llvm.pow.* .
> For example, That will avoid code like:
> %tmp1 = fpext %x to double
> %tmp2 = fpext %y to double
> %tmp3 = call @pow(%tmp1, %tmp2)
> %result = fptrunc %tmp3 to SomeSmallFloatingType  //
> The above code (the fpext/fptrunc stuff) also  might block other
> optimizations.
> And in optimization pass, we may have chance to minimize the fp size.

maybe such things are possible, but does "pow" need to be an intrinsic
in order to do them?  Check SimplifyLibCalls.cpp.  Also, even if we
decide to keep the llvm.pow.* intrinsics, it seems to me that we don't
need to have gcc emit it: if LLVM sees a call to "pow" with the right
prototype, and the call is marked "readnone" (maybe "readonly") then
it LLVM could automatically turn it into a call to llvm.pow.*.



More information about the llvm-commits mailing list