This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: combine simplification change: 2-for-2-with-lesser-cost
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: stevenb at suse dot de
- Cc: hans-peter dot nilsson at axis dot com, gcc at gcc dot gnu dot org
- Date: Tue, 20 Dec 2005 12:34:30 +0100
- Subject: Re: RFC: combine simplification change: 2-for-2-with-lesser-cost
> Date: Tue, 20 Dec 2005 11:13:06 +0100 (CET)
> From: Steven Bosscher <stevenb@suse.de>
> You really have to wonder if cleaning up this jump is a job combine
> should be doing.
I want it done there *only* because that's what it does for the
similar but even more complex cc0 code and because combine does
multi-insn simplifications in general. I suggest not being hung
up on it being a jump that's simplified.
Anyhow, I'd like to disconnect the un-cc0-ification of the CRIS
port while retaining performance, from overhaul of GCC passes as
much as possible, please, however TRT the overhaul may be.
> I would have thought we'd clean this up _before_
> combine
Me too... Might be a simple oversight somewhere. I'll have a
closer look; seems at a glance that gcse thinks it does this.
> (and no, I don't mean the tree optimizers, but e.g. CSE, or jump
> bypassing (even though the latter doesn't work for critical
> edges)).
FWIW, jump bypassing doesn't do anything transformationwise but
calling the usual cfgcleanup things. CFG apparently doesn't
perform the necessary kind of simplifications. See
rest_of_handle_jump2.
> Are
> there other cases, you think, where we fail to combine 2 insns into 2
> cheaper ones??
I don't know, but as combine seems to be the only pass
performing inter-insn simplifications, I'd guess so.
brgds, H-P