This is the mail archive of the
mailing list for the libstdc++ project.
Re: [PATCH] PR11706, optimize std::pow(T, int)
- 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
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?
Richard Guenther <richard dot guenther at uni-tuebingen dot de>