[ Only your 0/3 and 3/3 messages arrived -- or is this 1/3? ] On Wed, Nov 23, 2016 at 08:00:30PM +0100, Bernd Schmidt wrote: > Note that I misspelled the PR number in the 0/3 message :-/ > > On 11/23/2016 07:57 PM, Bernd Schmidt wrote: > >1. I noticed comparisons between set_src_cost and set_rtx_cost seemed to > >be invalid. There seems to be no good reason that insn_rtx_cost > >shouldn't use the latter. It also makes the numbers comparable to the > >ones you get from seq_cost. > > > Bernd
> PR rtl-optimization/78120 > * rtlanal.c (insn_rtx_cost): Use set_rtx_cost. > > Index: gcc/rtlanal.c > =================================================================== > --- gcc/rtlanal.c (revision 242038) > +++ gcc/rtlanal.c (working copy) > @@ -5211,7 +5211,7 @@ insn_rtx_cost (rtx pat, bool speed) > else > return 0; > > - cost = set_src_cost (SET_SRC (set), GET_MODE (SET_DEST (set)), speed); > + cost = set_rtx_cost (set, speed); > return cost > 0 ? cost : COSTS_N_INSNS (1); > } > Combine uses insn_rtx_cost extensively. I have tried to change it to use the full rtx cost, not just the source cost, a few times before, and it always only regressed. Part of it is that most ports' cost calculations are, erm, not so great -- every target we care about needs fixes. Let's please not try this in stage 3. Segher