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.
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).
The only advantage of llvm.pow.* is that it applies to vector operands
as well as scalars.
-Chris
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
