On Sat, Jul 1, 2017 at 9:06 AM, Jan Hubicka <hubi...@ucw.cz> wrote: >> >> > * config/rs6000/rs6000.c (emit_unlikely_jump): Adjust to new branch >> >> > probability data type. >> >> > >> >> > Index: rs6000.c >> >> > =================================================================== >> >> > --- rs6000.c (revision 249839) >> >> > +++ rs6000.c (working copy) >> >> > @@ -23514,10 +23514,9 @@ >> >> > static void >> >> > emit_unlikely_jump (rtx cond, rtx label) >> >> > { >> >> > - int very_unlikely = REG_BR_PROB_BASE / 100 - 1; >> >> > rtx x = gen_rtx_IF_THEN_ELSE (VOIDmode, cond, label, pc_rtx); >> >> > rtx_insn *insn = emit_jump_insn (gen_rtx_SET (pc_rtx, x)); >> >> > - add_int_reg_note (insn, REG_BR_PROB, very_unlikely); >> >> > + add_int_reg_note (insn, REG_BR_PROB, >> >> > profile_probability::very_unlikely ()); >> >> >> >> Hmmm isn't this very unlikely to work :) ? >> >> >> >> I used this as inspiration to do this for the arm ports but >> >> add_int_reg_note expects an integer but very_unlikely returns >> >> profile_probability ... >> > >> > It probably should be converted using to_reg_br_prob_base ? >> >> The comments in profile-count.h state that this should go away. >> >> We need advice from Honza about the preferred way to transform these idioms. > > I plan to change REG_BR_PROB notes to preserve all information from > profile_probability (this is needed to make RTL expansion splitting work as > expected), but for now they are still just REG_BR_PROB_BASE fixpoint. > > I think the code can stay as it is. I will add APIs for > emitting/interpretting > br_prob_nodes as followup (after debugging fixing issues with profile updating > which I can now detect with the new type) > > Thanks for looking into this.
Does the computed value of very_unlikely need to change for the new scale? Can the profile machinery provide a helper function or macro instead of the current calculation replicated in many ports? Thanks, David