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

[Jim Wilson]

Roger Sayle wrote:
> On Mon, 28 Jun 2004, Richard Kenner wrote:
>> 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

FYI  There is code in combine to try to avoid creating multiplies via 
combination.  Search for have_mult.  This just rejects a combination if 
the result has a MULT but the input insns did not.  This should be no 
longer necessary if we are using rtx_cost.  This is a possible argument 
in favor of the rtx_cost change, as using rtx_cost is cleaner and better 
than an explicit check for a MULT.

There is also the contains_muldiv function.  I am not sure exactly what 
it is for.  It came in via a jumbo merge patch from GCC2.  It looks 
suspiciously like it might be unnecessary with an rtx_cost check.

I'm worried about what the effect of the change will be though.  There 
are a lot of old targets with a lot of different ways of defining the 
rtx_cost macros.  Some of them are likely to behave oddly when rtx_cost 
is used like this.  For the most common cases, there is probably no bad 
effect though.  combine works best for integer alu/logical operations, 
and these are generally all one-cycle instructions for most targets of 
interest.  So maybe this won't be a serious problem.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com