> PING^2
Sorry, I thought it is approved once we settled down the multiplicatoin
datatype, but apparently never sent the email.
Patch is oK.
Honza
>
> On 5/24/22 13:35, Martin Liška wrote:
> > PING^1
> >
> > On 5/5/22 20:15, Martin Liška wrote:
> >> On 5/5/22 15:49, Jan Hubicka wrote:
> >>> Hi,
> >>>> The patch simplifies usage of the profile_{count,probability} types.
> >>>>
> >>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >>>>
> >>>> Ready to be installed?
> >>>
> >>> The reason I intentionally did not add * and / to the original API was
> >>> to detect situations where values that should be
> >>> profile_count/profile_probability are stored into integers, since
> >>> previous code used integers for everything.
> >>>
> >>> Having one to add apply_scale made him/her (mostly me :) to think if the
> >>> value is really just a fixed scale or it it should be better converted
> >>> to proper data type (count or probability).
> >>>
> >>> I guess now we completed the conversion so risk of this creeping in is
> >>> relatively low and the code indeed looks better.
> >>
> >> Yes, that's my impression as well that the profiling code is quite settled
> >> down.
> >>
> >>> It will make it bit
> >>> harder for me to backport jump threading profile updating fixes I plan
> >>> for 12.2 but it should not be hard.
> >>
> >> You'll manage ;)
> >>
> >>>> diff --git a/gcc/cfgloopmanip.cc b/gcc/cfgloopmanip.cc
> >>>> index b4357c03e86..a1ac1146445 100644
> >>>> --- a/gcc/cfgloopmanip.cc
> >>>> +++ b/gcc/cfgloopmanip.cc
> >>>> @@ -563,8 +563,7 @@ scale_loop_profile (class loop *loop,
> >>>> profile_probability p,
> >>>>
> >>>> /* Probability of exit must be 1/iterations. */
> >>>> count_delta = e->count ();
> >>>> - e->probability = profile_probability::always ()
> >>>> - .apply_scale (1, iteration_bound);
> >>>> + e->probability = profile_probability::always () /
> >>>> iteration_bound;
> >>> However this is kind of example of the problem.
> >>> iteration_bound is gcov_type so we can get overflow here.
> >>
> >> typedef int64_t gcov_type;
> >>
> >> and apply_scale takes int64_t types as arguments. Similarly the newly
> >> added operators,
> >> so how can that change anything?
> >>
> >>> I guess we want to downgrade iteration_bound since it is always either 0
> >>> or int.
> >>>> diff --git a/gcc/tree-switch-conversion.cc
> >>>> b/gcc/tree-switch-conversion.cc
> >>>> index e14b4e6c94a..cef26a9878e 100644
> >>>> --- a/gcc/tree-switch-conversion.cc
> >>>> +++ b/gcc/tree-switch-conversion.cc
> >>>> @@ -1782,7 +1782,7 @@ switch_decision_tree::analyze_switch_statement ()
> >>>> tree high = CASE_HIGH (elt);
> >>>>
> >>>> profile_probability p
> >>>> - = case_edge->probability.apply_scale (1, (intptr_t)
> >>>> (case_edge->aux));
> >>>> + = case_edge->probability / ((intptr_t) (case_edge->aux));
> >>>
> >>> I think the switch ranges may be also in risk of overflow?
> >>>
> >>> We could make operators to accept gcov_type or int64_t.
> >>
> >> As explained, they do.
> >>
> >> Cheers,
> >> Martin
> >>
> >>>
> >>> Thanks,
> >>> Honza
> >>
> >
>
