This is the mail archive of the
`libstdc++@gcc.gnu.org`
mailing list for the libstdc++ project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>*To*: Paolo Carlini <pcarlini at suse dot de>*Cc*: libstdc++ at gcc dot gnu dot org,Gabriel Dos Reis <gdr at integrable-solutions dot net>*Date*: Wed, 12 Jan 2005 16:28:31 +0100 (CET)*Subject*: Re: [PATCH] PR11706, optimize std::pow(T, int)

On Wed, 12 Jan 2005, Paolo Carlini wrote: > Richard Guenther wrote: > > Maybe Gaby wants to add something here, but I seem to remember that > we really dislike this kind of approach, calling back pow from __pow_helper > via a cast, thus giving away the info that the exponent is integer. We can dispatch directly to __builtin_pow[lf](), too, and the frontends are definitely using the integerness of the exponent here (otherwise it would not work). So it's only giving away this information from a language lawyer perspective. > And, after Zdenek nice patch, -funroll-loops should lead to optimal code. > Does it work as expected? Yes, __cmath_power is inlined and -funroll-loops is able to optimize the loop for constant powers. Though the approach in __cmath_power is not optimal, f.i. for a exponent of 27 we generate one more multiplication than with __builtin_pow(). Also, as we inline __cmath_power all the time now, we have icache and code-size regressions for not constant powers. With my hackish approach we could again remove these inlines. Also, having to enable -funroll-loops to make std::pow(x, 2) generate the same code as std::pow(x, 2.0) (which produces optimal code here) is counter-intuitive at least. Enabling -funroll-loops globally can have negative effects on runtime and code-size anyway (insert usual rant about us not unrolling constant rolling loops unconditionally). Until anybody can come up with a solution (and does so) that creates the same assembly for a standard -O2 compile for double x; std::pow(x, 2); std::pow(x, 2.0); ::pow(x, 2); I'm convinced my solution to the problem is both appropriate, least intrusive and robust. Can you think of a case where my patch would create behavior that is unwanted? Thanks, Richard. -- Richard Guenther <richard dot guenther at uni-tuebingen dot de> WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

**Follow-Ups**:**Re: [PATCH] PR11706, optimize std::pow(T, int)***From:*Richard Guenther

**Re: [PATCH] PR11706, optimize std::pow(T, int)***From:*Gabriel Dos Reis

**Re: [PATCH] PR11706, optimize std::pow(T, int)***From:*Gabriel Dos Reis

**References**:**Re: [PATCH] PR11706, optimize std::pow(T, int)***From:*Paolo Carlini

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |