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


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



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