linux-mips
[Top] [All Lists]

Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets

To: Nigel Stephens <nigel@mips.com>
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets
From: Richard Sandiford <rsandifo@redhat.com>
Date: Tue, 03 Aug 2004 06:30:38 +0100
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>, Ralf Baechle <ralf@linux-mips.org>, Richard Henderson <rth@redhat.com>, gcc-patches@gcc.gnu.org, linux-mips@linux-mips.org
In-reply-to: <410E9E25.7080104@mips.com> (Nigel Stephens's message of "Mon, 02 Aug 2004 21:03:49 +0100")
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <Pine.LNX.4.55.0407191648451.3667@jurand.ds.pg.gda.pl> <87hds49bmo.fsf@redhat.com> <Pine.LNX.4.55.0407191907300.3667@jurand.ds.pg.gda.pl> <20040719213801.GD14931@redhat.com> <Pine.LNX.4.55.0407201505330.14824@jurand.ds.pg.gda.pl> <20040723202703.GB30931@redhat.com> <20040723211232.GB5138@linux-mips.org> <Pine.LNX.4.58L.0407261325470.3873@blysk.ds.pg.gda.pl> <410E9E25.7080104@mips.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
Nigel Stephens <nigel@mips.com> writes:
> I have a patch against gcc-3.4 which makes the 64-bit inline shifts
> somewhat smaller on ISAs which include the conditional move
> (movz/movn) instructions, but more importantly removes all branches
> from the inline code - which can be very expensive on long pipeline
> CPUs, since in this sort of code they tend to cause many branch
> mispredicts. Let me know if you want me to extract the patch - here's
> a table of the number of instructions generated by the original md
> pattern and the patched version:
>
>               Instructions
>               Old     New
> ashldi3               12      9
> ashrdi3               12      12
> lshrdi3               12      9
>
>
> If people really don't like the inline expansion, then maybe it could be
> enabled or disabled by a new -m option.

IMO, controlling with optimize_size would be enough.  But it sounds from
your description like the patch just adds a new hard-coded multi-insn
asm string.  Is that right?  If so, I'd really like to avoid that.

It would much better IMO if we handle this in the target-independent
parts of the compiler.  We can already open-code certain non-native
operations, it's "just" that wide shifts are a missing case.

If we handle it in a target-independent way, with each insn exposed
separately, we will be able to optimize special cases better.
We'll also get the usual scheduling benefits.

Richard

<Prev in Thread] Current Thread [Next in Thread>