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] rs6000 branch probability changes


> On Sat, Jul 1, 2017 at 9:06 AM, Jan Hubicka <hubicka@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?

There is PROB_VERY_UNLIKELY macro which should be used in this context.  Not
sure how and whhen this very_unlikely got in.  It is defined as 
(REG_BR_PROB_BASE / 2000 - 1) perhaps 2000 was consider just too strong here?

Honza
> 
> Thanks, David


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