This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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]

Re: [PATCH] Optimize x*x*x*x*x*x using 3 multiplications.


Hi Gaby,
> Just to make sure I understand what you're acheiving.
>
> | One piece of ugliness is that we now have to disable the constant
> | folding transformation of pow(x,2) into x*x.
>
> People have been recently suggesting to forward calls to pow() in the
> hope that it would, for example, expand pow(x, 2) into x * x.  What
> are the reasons for not doing that?

The distinction needs to be made between tree-level constant folding
and RTL expansion and later passes.  Basically, the game plan is
for x*x to be converted into pow(x,2) at the tree-level, and then
converted back to x*x at the RTL-level.  Hence pow(x,2) will always
generate x*x, but the pass where that particular optimization will
be performed will be moved later in the compiler.

We only have a problem with infinite recursion if we convert from X to Y
and from Y to X in a single pass.  Hence, at the tree-level, we use a
high level of abstraction, pow(x,2), but when we lower to RTL, perform
the reverse transformation.  My changes to fold-const performed the
first step, and my changes to builtins.c performed the second.


[This is very similar to things like address calculations where we
strive to use higher levels of abstraction such as multiplications
at the early in the compiler, but then convert them back to shifts
and additions prior to code generation.]


Does this make things any clearer?



The std::pow thread on "gcc" is an insteresting one.  I too would
recommend forwarding std::pow(double,int) to std::pow(double,double) for
the case where the second argument is __builtin_constant_p.  An even
better solution would be to provide a __builtin_powi function directly
that is always guaranteed to expanded inline, independently of -Os and
-ffast-math, and that expands to a loop (that can be unrolled!) even
when the second argument isn't constant.  This functionality doesn't
correspond to a function in libc, but is useful for the both the
fortran and C++ front-ends.

Roger
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]