Mehdi Amini via llvm-dev
2017-Jan-12 17:33 UTC
[llvm-dev] The most efficient way to implement an integer based power function pow in LLVM
> On Jan 12, 2017, at 5:03 AM, Antoine Pitrou via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, 9 Jan 2017 11:43:17 -0600 > Wei Ding via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Hi, >> >> I want an efficient way to implement function pow in LLVM instead of >> invoking pow() math built-in. For algorithm part, I am clear for the logic. >> But I am not quite sure for which parts of LLVM should I replace built-in >> pow with another efficient pow implementation. Any comments and feedback >> are appreciated. Thanks! > > In Numba, we have decided to optimize some usages of the power function > in our own front-end, so that LLVM IR gets an already optimized form, > as we have found that otherwise LLVM may miss some optimization > opportunities. YMMV.It seems to me that it would be more interesting to gather these misoptimization and fix LLVM to catch them.> > (e.g. we detect that the exponent is a compile-time constant and > transform `x**3` into `x*x*x`)This seems definitely in the scope of what LLVM could do, potentially with TTI. — Mehdi> > Note that not only `pow(x, 3)` can be slower than `x*x*x`, but it may > also have some precision issues, as it goes through log() and exp() > calls. > > Regards > > Antoine. > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Friedman, Eli via llvm-dev
2017-Jan-12 17:58 UTC
[llvm-dev] The most efficient way to implement an integer based power function pow in LLVM
On 1/12/2017 9:33 AM, Mehdi Amini via llvm-dev wrote:>> On Jan 12, 2017, at 5:03 AM, Antoine Pitrou via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Mon, 9 Jan 2017 11:43:17 -0600 >> Wei Ding via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> Hi, >>> >>> I want an efficient way to implement function pow in LLVM instead of >>> invoking pow() math built-in. For algorithm part, I am clear for the logic. >>> But I am not quite sure for which parts of LLVM should I replace built-in >>> pow with another efficient pow implementation. Any comments and feedback >>> are appreciated. Thanks! >> In Numba, we have decided to optimize some usages of the power function >> in our own front-end, so that LLVM IR gets an already optimized form, >> as we have found that otherwise LLVM may miss some optimization >> opportunities. YMMV. > It seems to me that it would be more interesting to gather these misoptimization and fix LLVM to catch them. > >> (e.g. we detect that the exponent is a compile-time constant and >> transform `x**3` into `x*x*x`) > This seems definitely in the scope of what LLVM could do, potentially with TTI.LLVM already does this... but only if the pow() call is marked "fast". IEEE 754 pow() is supposed to be correctly rounded, but (x*x)*x has an extra rounding step. -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Steve (Numerics) Canon via llvm-dev
2017-Jan-12 19:04 UTC
[llvm-dev] The most efficient way to implement an integer based power function pow in LLVM
> On Jan 12, 2017, at 12:58 PM, Friedman, Eli via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/12/2017 9:33 AM, Mehdi Amini via llvm-dev wrote: >>> On Jan 12, 2017, at 5:03 AM, Antoine Pitrou via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On Mon, 9 Jan 2017 11:43:17 -0600 >>> Wei Ding via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>>> Hi, >>>> >>>> I want an efficient way to implement function pow in LLVM instead of >>>> invoking pow() math built-in. For algorithm part, I am clear for the logic. >>>> But I am not quite sure for which parts of LLVM should I replace built-in >>>> pow with another efficient pow implementation. Any comments and feedback >>>> are appreciated. Thanks! >>> In Numba, we have decided to optimize some usages of the power function >>> in our own front-end, so that LLVM IR gets an already optimized form, >>> as we have found that otherwise LLVM may miss some optimization >>> opportunities. YMMV. >> It seems to me that it would be more interesting to gather these misoptimization and fix LLVM to catch them. >> >>> (e.g. we detect that the exponent is a compile-time constant and >>> transform `x**3` into `x*x*x`) >> This seems definitely in the scope of what LLVM could do, potentially with TTI. > > LLVM already does this... but only if the pow() call is marked "fast". IEEE 754 pow() is supposed to be correctly rounded, but (x*x)*x has an extra rounding step.pow( ) is not supposed to be correctly rounded. IEEE 754 recommends that a correctly rounded power function exist [9.2], but does not recommend or require that this be the default pow( ) function. [Note: it was not actually shown until quite late in the IEEE 754 revision process that it was even possible to have a reasonably efficient correctly-rounded pow( ) function, and such a function is at minimum an order of magnitude slower than a good sub-ulp-accurate-but-not-correctly-rounded implementation. Most 754 committee members would recommend that the default pow( ) function *not* be correctly rounded.] In a good math library, however, pow( ) should absolutely be sub-ulp accurate, which means that it should *not* be implemented via log( ) and exp( ), and indeed, most math libraries don’t do that. Just to provide some example data, for single-precision x in [1,2) on current OS X: The worst-case error of x*x*x is 1.28736 ulp The worst-case error of powf(x, 3) is 0.500013 ulp The RMS error of x*x*x is 0.585066 ulp The RMS error of powf(x,3) is 0.499984 ulp – Steve
Reasonably Related Threads
- The most efficient way to implement an integer based power function pow in LLVM
- The most efficient way to implement an integer based power function pow in LLVM
- The most efficient way to implement an integer based power function pow in LLVM
- [LLVMdev] pow operator on Windows
- [LLVMdev] SimplifyLibCalls doesn't check TLI for LibFunc availability