Re: [PATCH] Properly honor param_max_fsm_thread_path_insns in backwards threader

[Aldy Hernandez <aldyh@redhat.com>]

On Tue, Aug 2, 2022 at 1:59 PM Richard Biener <rguenther@suse.de> wrote:
>
> On Tue, 2 Aug 2022, Aldy Hernandez wrote:
>
> > On Tue, Aug 2, 2022 at 1:45 PM Richard Biener <rguenther@suse.de> wrote:
> > >
> > > On Tue, 2 Aug 2022, Aldy Hernandez wrote:
> > >
> > > > Unfortunately, this was before my time, so I don't know.
> > > >
> > > > That being said, thanks for tackling these issues that my work
> > > > triggered last release.  Much appreciated.
> > >
> > > Ah.  But it was your r12-324-g69e5544210e3c0 that did
> > >
> > > -  else if (n_insns > 1)
> > > +  else if (!m_speed_p && n_insns > 1)
> > >
> > > causing the breakage on the 12 branch.  That leads to a simpler
> > > fix I guess.  Will re-test and also backport to GCC 12 if successful.
> >
> > Huh.  It's been a while, but that looks like a typo.  That patch was
> > supposed to be non-behavior changing.
>
> Exactly my thinking so reverting it shouldn't be a reason for
> detailed questions.  Now, the contains_hot_bb computation is,

Sorry for the pain.

Thanks for taking care of this.
Aldy

> that one was introduced by Honza in r7-6476-g0f0c2cc3a17efa
> together with the comment and a testcase.
>
> So - Honza, what was the reasoning to look at raw BB counts here
> rather than for example the path entry edge count?
>
> Richard.
>