This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] expmed.c: Fix PR 23971 - slow synth_mult.
- From: Roger Sayle <roger at eyesopen dot com>
- To: Falk Hueffner <falk at debian dot org>
- Cc: Kazu Hirata <kazu at codesourcery dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 21 Sep 2005 09:45:30 -0600 (MDT)
- Subject: Re: [patch] expmed.c: Fix PR 23971 - slow synth_mult.
On Wed, 21 Sep 2005, Falk Hueffner wrote:
> Actually, 0.6 seconds for one line of source still seems quite
> excessive... While this patch certainly seems like a good idea, I'm
> wondering whether we shouldn't just additionally put an upper limit to
> the number of instructions generated, since it seems unlikely that
> expanding a multiply to more than say 12 insns is really such a great
> idea.
One possible hack to hide this problem is to change the default
processor that the alpha backend targets. Currently, I believe
we default rtx_costs to the EV4 processor, where a multiplication
costs 23 instructions, but a shift costs 2 and an addition costs 1.
Using the EV5 processor as a default, lowers the multiplication
cost to 8 (SImode) or 12 (DImode) instructions, and to the even
more recent EV6, further still to 7 instructions (for both SImode
and DImode).
I know that in the last five years or so, I've only had access to
an EV67. Given that EV6's are probably the most common wildtype,
we're probably artificially penalizing code by sometimes replacing
multiplications with sequences that are about three times slower
on "modern" systems.
Roger
--