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 rguent...@suse.de 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.

Reply via email to