Re: [PATCH] PR11706, optimize std::pow(T, int)

[Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>]

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/