https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #13 from Than McIntosh <thanm at google dot com> ---
I've made a stab at revising the test case to try to trigger the long compile
time that I'm still seeing the real application code. Still not quite there
yet (revised testcase takes maybe a minute to compile, original 45 mins) -- I
don't understand quite why.
To compile the revised testcase:
gccgo -g -c -O2 auxiliary.go
gccgo -g -c -O2 -I . generated2.go
Having more than one package seems to be part of the equation (changes aliasing
in some way? hard to tell). Profile still seems to be pointing to the same
routines as before:
(pprof) top15
Showing nodes accounting for 41.67s, 83.29% of 50.03s total
Dropped 986 nodes (cum <= 0.25s)
Showing top 15 nodes out of 88
flat flat% sum% cum cum%
15.12s 30.22% 30.22% 17.43s 34.84% dominated_by_p
7.96s 15.91% 46.13% 33.78s 67.52% get_continuation_for_phi
4.05s 8.10% 54.23% 4.05s 8.10% canon_value_cmp (inline)
3.70s 7.40% 61.62% 8.35s 16.69% canonicalize_values_star
2.31s 4.62% 66.24% 2.31s 4.62% dom_convert_dir_to_idx (inline)
2.29s 4.58% 70.82% 2.29s 4.58% tree_check (inline)
1.34s 2.68% 73.50% 4.25s 8.49% set_slot_part
1.11s 2.22% 75.71% 1.15s 2.30% gimple_vuse (inline)
1.05s 2.10% 77.81% 1.05s 2.10% loc_cmp
0.64s 1.28% 79.09% 0.64s 1.28% bitmap_list_find_element (inline)
0.52s 1.04% 80.13% 0.88s 1.76% hash_table::find_slot_with_hash
