This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Check rtx_costs in combine.c's try_combine


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]