https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> --- 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.
