https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jeffreyalaw at gmail dot com
--- Comment #17 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to rguent...@suse.de from comment #15)
> On Mon, 8 Nov 2021, aldyh at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
> >
> > --- Comment #13 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> > Since DOM is the only threading pass that keeps more or less accurate
> > profiling data, here's a very wild guess.
> >
> > The pre-loop DOM threading pass does not thread some paths because of
> > the restrictions in place, which causes one of the post-loop backward
> > threaders (thread2 or threadfull2) to pick them up. These will likely
> > not produce accurate profile info.
> >
> > And I would also guess that the reason DOM3 (post loop) did not pick up the
> > threads was because the IL was sufficiently complicated for the simple path
> > discovery bits in the forward threader to catch.
> >
> > This is all highly speculative, but that's the only scenario I can imagine
> > where this commit caused a profiling regression.
>
> I think the important take-away is that we need to fix the profile
> updating code (which is non-existant!) for the backwards threader
> by looking at what the forward threader does, otherwise at least
> profile-guided optimizations will be quite broken.
I totally agree. Perhaps we could close this PR as WONTFIX since the test is
itself is deceiving, and open a new PR with the actual issue.
FWIW, in Jeff's original opinion:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576437.html
...I mention that gcc.dg/shrink-wrap-loop.c shows a regression due to profiling
differences. Perhaps we could open a PR for that instead.
