https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #29 from Andrew Macleod <amacleod at redhat dot com> ---
Huh. Do we calculate *all* paths ahead of time?
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 ()
That functions looks kind of quadratic or worse in nature, and when I run it
with GDB and force a stop at a random point, I see:
(gdb) p m_paths->m_vec
$2 = (vec<vec<jump_thread_edge*, va_heap, vl_ptr>*, va_heap, vl_embed> *)
0x12f50750
(gdb) p *(m_paths->m_vec)
$3 = {m_vecpfx = {m_alloc = 745039, m_using_auto_storage = 0, m_num = 572595}}
(gdb) p cand_path_num
$4 = 309148
(gdb) p curr_path_num
$5 = 0
Am I reading that right? 572,595 paths, of which we are looking at candidate
#309,148 ??
It *appears* that this is called for path 0, then path 0 is removed and its all
done over again with one less path in the vector.
At one point a little later in back_jt_path_registry::update_cfg I see:
p m_num_threaded_edges
$19 = 18669
and the size of the m_path vector is down to 558637
(gdb) p *(m_paths.m_vec)
$23 = {m_vecpfx = {m_alloc = 745039, m_using_auto_storage = 0, m_num = 558637}}
back_jt_path_registry::update_cfg() makes a lot of calls to
back_jt_path_registry::duplicate_thread_path which then invokes
adjust_paths_after_duplication
All this time is spend here copying and moving things.
Something seems horribly wrong about that
