https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97094
Jan Hubicka <hubicka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2024-12-15
Status|UNCONFIRMED |NEW
CC| |hubicka at gcc dot gnu.org
--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
We seems to spend most of time sorting PHI edges
#0 0x000000000231f835 in mergesort<sort_ctx> (in=<optimized out>,
c=0x7fffffffd530, n=24, out=0x14a29790 "\236\204", tmp=<optimized out>) at
../../gcc/sort.cc:230
#1 0x000000000231f7be in mergesort<sort_ctx> (in=0x14a29688 "\277\204",
c=0x7fffffffd530, n=47, out=0x14a29688 "\277\204", tmp=<optimized out>) at
../../gcc/sort.cc:210
#2 0x000000000231f7d6 in mergesort<sort_ctx> (in=0x14a29688 "\277\204",
c=0x7fffffffd530, n=94, out=0x14a2a250 "\212\202", tmp=<optimized out>) at
../../gcc/sort.cc:212
#3 0x000000000231f7be in mergesort<sort_ctx> (in=0x14a29398 "\035\205",
c=0x7fffffffd530, n=188, out=0x14a29f60 "\004\204", tmp=<optimized out>) at
../../gcc/sort.cc:210
#4 0x000000000231f7d6 in mergesort<sort_ctx> (in=0x14a29398 "\035\205",
c=0x7fffffffd530, n=377, out=0x14a29398 "\035\205", tmp=<optimized out>) at
../../gcc/sort.cc:212
#5 0x000000000231f7be in mergesort<sort_ctx> (in=0x14a287d0 "\226\206",
c=0x7fffffffd530, n=754, out=0x14a287d0 "\226\206", tmp=<optimized out>) at
../../gcc/sort.cc:210
#6 0x000000000231f7d6 in mergesort<sort_ctx> (in=0x14a287d0 "\226\206",
c=0x7fffffffd530, n=1508, out=0x4710f50 "\316z", tmp=<optimized out>) at
../../gcc/sort.cc:212
#7 0x000000000231f7be in mergesort<sort_ctx> (in=0x14a258b0 "z\214",
c=0x7fffffffd530, n=3016, out=0x470e030 "\352t", tmp=<optimized out>) at
../../gcc/sort.cc:210
#8 0x000000000231f7be in mergesort<sort_ctx> (in=0x14a1fa70 "B\230",
c=0x7fffffffd530, n=6032, out=0x47081f0 "\353t", tmp=<optimized out>) at
../../gcc/sort.cc:210
#9 0x000000000231f7d6 in mergesort<sort_ctx> (in=0x14a1fa70 "B\230",
c=0x7fffffffd530, n=12065, out=0x14a1fa70 "B\230", tmp=<optimized out>) at
../../gcc/sort.cc:212
#10 0x000000000231f7be in mergesort<sort_ctx> (in=0x14a08168 <incomplete
sequence \307>, c=0x7fffffffd530, n=24130, out=0x14a08168 <incomplete sequence
\307>, tmp=<optimized out>)
at ../../gcc/sort.cc:210
#11 0x000000000231f7be in mergesort<sort_ctx> (in=0x149d8f60 "\001",
c=0x7fffffffd530, n=48259, out=0x149d8f60 "\001", tmp=<optimized out>) at
../../gcc/sort.cc:210
#12 0x000000000231fc00 in gcc_qsort (vbase=0x149d8f60, n=48259, size=<optimized
out>, cmp=<optimized out>) at ../../gcc/sort.cc:268
#13 0x000000000103ceb0 in prune_unused_phi_nodes (phis=0x13984d28,
kills=<optimized out>, uses=0x5727910) at ../../gcc/tree-into-ssa.cc:819
#14 insert_phi_nodes_for (var=var@entry=0x7fffd1c2e6c0,
phi_insertion_points=phi_insertion_points@entry=0x13984d28,
update_p=update_p@entry=true) at ../../gcc/tree-into-ssa.cc:975
#15 0x000000000103d901 in insert_updated_phi_nodes_for (var=0x7fffd1c2e6c0,
dfs=dfs@entry=0x15eef880, update_flags=update_flags@entry=2048) at
../../gcc/tree-into-ssa.cc:3286
#16 0x000000000103e114 in update_ssa (update_flags=update_flags@entry=2048) at
../../gcc/tree-into-ssa.cc:3558
#17 0x000000000120feca in execute_update_addresses_taken () at
../../gcc/tree-ssa.cc:2292
#18 0x0000000000e9d5bd in execute_function_todo (fn=0x7ffff3b45600,
data=<optimized out>) at ../../gcc/passes.cc:2079
#19 0x0000000000e9dba8 in execute_todo (flags=2132064) at
../../gcc/passes.cc:2155
It has 48259 parameters.
Later a lot of time goes to
#0 0x0000000000a7f306 in alloc_page (order=18) at ../../gcc/ggc-page.cc:786
#1 ggc_internal_alloc (size=size@entry=262136, f=f@entry=0x0, s=s@entry=0,
n=n@entry=1) at ../../gcc/ggc-page.cc:1295
#2 0x00000000010775c3 in ggc_internal_alloc (s=262136) at ../../gcc/ggc.h:136
#3 allocate_phi_node (len=<optimized out>) at ../../gcc/tree-phinodes.cc:119
#4 resize_phi_node (phi=<optimized out>, len=<optimized out>) at
../../gcc/tree-phinodes.cc:258
#5 reserve_phi_args_for_new_edge (bb=<optimized out>) at
../../gcc/tree-phinodes.cc:295
#6 0x0000000001011d13 in cleanup_empty_eh_merge_phis (new_bb=0x7fffe6546780,
old_bb=old_bb@entry=0x7fffe6546720, old_bb_out=old_bb_out@entry=0x7fffe3b7cb10,
change_region=change_region@entry=true) at ../../gcc/tree-eh.cc:4507
#7 0x0000000001012124 in cleanup_empty_eh (lp=0x7fffeb2a0050) at
../../gcc/tree-eh.cc:4756
/* Do a post-order traversal of the EH region tree. Examine each
post_landing_pad block and see if we can eliminate it as empty. */
static bool
cleanup_all_empty_eh (void)
{
bool changed = false;
eh_landing_pad lp;
int i;
/* The post-order traversal may lead to quadraticness in the redirection
of incoming EH edges from inner LPs, so first try to walk the region
tree from inner to outer LPs in order to eliminate these edges. */
for (i = vec_safe_length (cfun->eh->lp_array) - 1; i >= 1; --i)
{
lp = (*cfun->eh->lp_array)[i];
if (lp)
changed |= cleanup_empty_eh (lp);
}
/* Now do the post-order traversal to eliminate outer empty LPs. */
for (i = 1; vec_safe_iterate (cfun->eh->lp_array, i, &lp); ++i)
if (lp)
changed |= cleanup_empty_eh (lp);
return changed;
}
So it seems that some logic to kill the quadraticness is already present, but
not good enough.
