> >
> > A couple cycles ago I separated most of code to distinguish between the
> > back and forward threaders. There is class jt_path_registry that is
> > common to both, and {fwd,back}_jt_path_registry for the forward and
> > backward threaders respectively. It's not perfect, but it's a start.
>
> Yep, it's back_jt_path_registry::update_cfg / duplicate_thread_path
> that lacks the updates.
duplicate_thread_path has profile update (using
profile_bb_update_for_threading and
scale_bbs_frequencies_profile_count). It will however silently keep
profile misupdated if the cfg were originally inconsistent with the
threaded path (in which case it is intended to keep profile
inconsistent, but we should have it logged so we know it is "okay after
all"). I will add logging same as in profile_bb_update_for_threading, so
these things are easier to figure out.
What happens in the test is that we have __builtin_constant_p that
blocks early threading and we thread only after profile is constructed.
I did not check by hand if the original profile is guessed
inconsistently.
Honza
>
> Richard.
>
> > Aldy
> >
