This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Check rtx_costs in combine.c's try_combine
- From: Daniel Jacobowitz <drow at false dot org>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 28 Jun 2004 00:58:10 -0400
- Subject: Re: [PATCH] Check rtx_costs in combine.c's try_combine
- References: <Pine.LNX.4.44.0406272112230.8955-100000@www.eyesopen.com>
On Sun, Jun 27, 2004 at 10:37:44PM -0600, Roger Sayle wrote:
>
> The following patch adds an additional test to combine.c's try_combine
> to only allow instructions to be merged/combined if the backend's
> TARGET_RTX_COST macro indictates that the replacement is atleast as
> cheap as the original. Historically, GCC's "combine" pass has used
> a greedy algorithm that always attempts to build complex composite
> instructions that are recognized by the back-end independent of any
> cost metric. Increasingly with modern processors, the more complex
> instructions supported are an ISA are not automatically better than
> their component parts.
>
> The thought of adding a check on rtx_cost into combine has been mentioned
> several times on the gcc patches, there's a notable thread from 2000,
> however I've been unable to find anyone actually propose a patch, show
> a demonstrable benefit and/or measure the compilation time impact.
> Hopefully, the patch below can be made acceptable whilst we're still in
> stage 1.
I think this is wonderful! I was recently working on a port where
shifts are extremely expensive (about three times as expensive as a
conditional branch), and I had a bit of a fistfight with combine about
it.
Have you considered extending the same principle to the if-conversion
code? It's a tricky problem in that BRANCH_COST uses an incomparable
metric to TARGET_RTX_COSTS; but it is full of hard-wired assumptions
that shifts are cheap. I'm not sure whether modern x86 processors are
harmed by this, but I wouldn't be surprised.
--
Daniel Jacobowitz