This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Reduce the number of extraneous rtl when expandingmutliply
- From: Roger Sayle <roger at eyesopen dot com>
- To: Andrew Pinski <pinskia at physics dot uc dot edu>
- Cc: gcc-patches at gcc dot gnu dot org, Steven Bosscher <stevenb at suse dot de>
- Date: Fri, 12 Nov 2004 09:12:58 -0700 (MST)
- Subject: Re: [PATCH] Reduce the number of extraneous rtl when expandingmutliply
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?