https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81889
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> --- Created attachment 42838 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42838&action=edit old non-functional patch VRP1 has figured out ranges that bound the iteration of the loop in question but there's too much stuff happening inbewteen that and cunrool to have any hope to preserve it enough. niter analysis would benefit from some ad-hoc walking of dominator stmts like simplify_using_initial_conditions does for the purpose of figuring an upper bound for the iteration... like the attached old non-functional patch computing ranges for a GENERIC expr which nowadays should use register_edge_assert_for () to get at "asserts" for conditions it visits and extract_range_for_var_from_comparison_expr to get at range info. That said, niter analysis might want to populate a sparse lattice of ranges seeded by dominating conditions and propagate those via the suggested recursion (lacking SSA use->def handling). Not sure if a sparse lattice can be easily instantiated with the current vr_values class - it seems to include lattice storage at the moment rather than abstracting that. Note that re-ordering passes to somehow make VRP2 appear before cunroll might also fix things but cunroll is in the loop pipeline and VRP2 is not. Hacking things up so that early range info is copied/preserved enough might be possible for this particular case.
