Re: [PATCH] Reduce the number of extraneous rtl when expandingmutliply

[Roger Sayle <roger at eyesopen dot com>]

On Fri, 12 Nov 2004, Andrew Pinski wrote:
> On Nov 9, 2004, at 10:41 PM, Roger Sayle wrote:
> > On Tue, 9 Nov 2004, Andrew Pinski wrote:
> >> 	* expmed.c (expand_mult_const): If we have an alg_m as the first
> >> 	operation and there is only one other operation, then don't copy
> >> 	the register into a new one.
> >
> > I don't think this is safe.  I was just about to approve this patch
> > (under the condition that you mention PR middle-end/18293 in the
> > ChangeLog) when I it struck me that we can't use op0 directly as
> > the accumulator, as op0's pseudo mustn't be modified, but the
> > accum pseudo may potentially be modified in place.
>
> It does not matter if it is not safe or not anymore, we can produce
> worse code with this patch as the IV-OPT cost analysis is being messed
> up by not having the extra copy in there.

Is there a test case in the testsuite that can be used to detect this
problem?  Relying on this superfluous instruction is fragile, and the
proposal to fast-path multiplications by powers-of-two using expand_shift
in expand_mult_const is not only a good one (to improve compile-time),
but is also useful to address Zdenek's "x + x + x + x" issue with loop
transformations.  If we canonicalize "x + x" as "x * 2" in fold, we'll
need to avoid pushing synth_mult even higher up on GCC's profiles.

For those unaware of why I'm so concerned about avoiding the performance
overhead of synth_mult, Andi Kleen's recent analysis of Linux kernel
compilation at http://gcc.gnu.org/ml/gcc/2004-11/msg00108.html shows
synth_mult as 18th in the list of oprofile hot spots (which includes
vmlinux, libc.so and as)!  Avoiding synth_mult for common powers of
two would be a good thing (and resolve PR18293), if it wasn't for this
mysterious iv-opts glitch.

Does the iv-opts problem have a bugzilla PR?

Roger
--