https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 10 Nov 2021, aldyh at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906 > > Aldy Hernandez <aldyh at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot > gnu.org > > --- Comment #14 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #13) > > On Wed, 10 Nov 2021, aldyh at gcc dot gnu.org wrote: > > > > So, we could fix this either by relaxing the restriction with your patch, > > > or by > > > teaching should_duplicate_loop_header_p that an incoming edge can resolve > > > the > > > conditional in the header? > > > > Yes. I think the latter would be cleaner but the former has an (ugly) > > patch already (see above). Not sure how difficult it is to do the latter, > > The idea is actually straightforward. Assuming I have the right edge, this > would get us the result: > > @@ -60,6 +63,24 @@ should_duplicate_loop_header_p (basic_block header, class > loop *loop, > if (optimize_loop_for_size_p (loop) > && !loop->force_vectorize) > { > + if (gcond *last = safe_dyn_cast <gcond *> (last_stmt (header))) > + { > + gimple_ranger ranger; > + int_range<2> r; > + path_range_query path (ranger, /*resolve=*/true); > + auto_vec<basic_block> bbs (2); > + edge e = loop_preheader_edge (loop); > + > + gcc_checking_assert (e->dest == header); > + bbs.quick_push (header); > + bbs.quick_push (e->src); > + bitmap imports = ranger.gori ().imports (header); > + path.compute_ranges (bbs, imports); > + path.range_of_stmt (r, last); > + r.dump (); > + fputc ('\n', stderr); Nice. Does composing the path from the exact two BBs mean that it won't pick up a case like if (n > 0) if (k > 0) for (; n > 0;) ... where the n > 0 outer condition is on the predecessor from e->src? Or is the path merely built to denote the fact that we're interested on the entry edge of the loop only (on the backedge the condition wouldn't be known)?
