Hi, > 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.*. Ciao, Duncan. _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits