https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #26 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 19 Jan 2024, juzhe.zhong at rivai dot ai wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495 > > --- Comment #22 from JuzheZhong <juzhe.zhong at rivai dot ai> --- > (In reply to Richard Biener from comment #21) > > I once tried to avoid df_reorganize_refs and/or optimize this with the > > blocks involved but failed. > > I am considering whether we should disable LICM for RISC-V by default if > vector > is enabled ? > Since the compile time explode 10 times is really horrible. I think that's a bad idea. It only explodes for some degenerate cases. The best would be to fix invariant motion to keep DF up-to-date so it can stop using df_analyze_loop and instead analyze the whole function. Or maybe change it to use the rtl-ssa framework instead. There's already param_loop_invariant_max_bbs_in_loop: /* Process the loops, innermost first. */ for (auto loop : loops_list (cfun, LI_FROM_INNERMOST)) { curr_loop = loop; /* move_single_loop_invariants for very large loops is time consuming and might need a lot of memory. For -O1 only do loop invariant motion for very small loops. */ unsigned max_bbs = param_loop_invariant_max_bbs_in_loop; if (optimize < 2) max_bbs /= 10; if (loop->num_nodes <= max_bbs) move_single_loop_invariants (loop); } it might be possible to restrict invariant motion to innermost loops when the overall number of loops is too large (with a new param for that). And when the number of innermost loops also exceeds the limit avoid even that? The above also misses a optimize_loop_for_speed_p (loop) check (probably doesn't make a difference, but you could try).
