https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |law at gcc dot gnu.org
--- Comment #31 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to [email protected] from comment #30)
> On Wed, 4 Sep 2024, amacleod at redhat dot com wrote:
> > I tried running valgrind, which died, but up to that point it showed 77% of
> > the
> > time spend in the body of
> > back_jt_path_registry::adjust_paths_after_duplication ()
>
> Hmm, I can have a look there if you don't beat me to it (though the
> profiles didn't have this part in AFAIR).
[Some background before somebody shoots me.]
This function should really go. It was leftover from a PR I worked on a long
time ago, before the backwards threader rewrite. In working on it I realized
that we were threading a lot of sub-threads that could be simplified. I
suggested this to Jeff, who may remember the details. There is no testcase
unfortunately.
It seemed cheap at the time, since the original backwards threader could only
thread a handful of things, so the number of threads was always in the single
digits.
The function is ugly. I thought about removing it as part of the threader
rewrite, but was wasn't brave enough because we didn't have a testcase and I
had forgotten the details.
Ok, enough excuses.
Andrew was playing with this last night and saw a reduction from 1700 seconds
to 27 (?? in a subset of the testcase??) by just removing it.
We either need to rewrite this function, or delete it altogether. I vote for
the latter. It's a micro optimization that is obviously too expensive to be
worth it. Perhaps we should benchmark how many times it actually triggers in a
bootstrap, and what the supposed code size savings are.
