<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite">Another benefit I can imagine is that using llvm.pow.* will make code more effective than using @pow.<br> As llvm began to support apfloat, and as the llvm LangRef says "You can use <tt>llvm.pow</tt> 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.* .<br> <br> For example, That will avoid code like:<br> <br> %tmp1 = fpext %x to double<br> %tmp2 = fpext %y to double<br> %tmp3 = call @pow(%tmp1, %tmp2)<br> %result = fptrunc %tmp3 to SomeSmallFloatingType //<br> <br> The above code (the fpext/fptrunc stuff) also might block other optimizations.<br> And in optimization pass, we may have chance to minimize the fp size.</blockquote><br></div><div>Duncan is right: there is no advantage of llvm.pow here over pow/powf, etc. LLVM optimization passes can and do hack on standard libc functions (see simplifylibcalls pass).</div><div><br class="webkit-block-placeholder"></div><div>The only advantage of llvm.pow.* is that it applies to vector operands as well as scalars.</div><div><br class="webkit-block-placeholder"></div><div>-Chris</div><br></body></html>