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

Zhou Sheng zhousheng00 at gmail.com
Fri Nov 23 02:30:51 PST 2007


Hi Ciao,

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.


Sheng.




2007/11/23, Duncan Sands <baldrick at free.fr>:
>
> Hi Sheng,
>
> > Here is the patch to make llvm-gcc/llvm-g++ emit llvm.pow.* when errno
> > disabled.
>
> thanks for doing this.  Yet I have to wonder whether there's any point
> to using the llvm.pow.* intrinsic, or for that intrinsic to exist.
> LLVM doesn't seem to do anything with it, so presumably the only
> reason for it is so that LLVM knows that it is "pure".  But nowadays
> gcc tells LLVM that directly.  Look:
>
> #include <math.h>
> double f(double x, double y) {
>   return pow(x,y);
> }
>
> If you compile it with -fno-math-errno then pow gets declared as
>
> declare double @pow(double, double) nounwind readonly
>
> [I'm not sure why it is marked readonly rather than readnone].
> [If you don't use -fno-math-errno then it is not declared readonly,
> which is correct because it can set errno].
> Since yesterday, alias analysis knows how to deal with readonly
> and readnone functions.  So all the benefit you would get from
> the intrinsic is already there!
>
> So how about removing the llvm.pow.* intrinsic and other ones like it
> instead?
>
> Ciao,
>
> Duncan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20071123/62dd8f20/attachment.html>


More information about the llvm-commits mailing list