[Bug tree-optimization/114052] [11/12/13/14 Regression] Wrong code at -O2 for well-defined infinite loop

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #5)
> So if I understand it right, you want to determine the property that if the
> loop header is executed then BB containing undefined behavior at that
> iteration will be executed, too.
> 
> modref tracks if function will always return and if it can not determine it,
> it will set the side_effect flag. So you can check for that in modref
> summary.
> It uses finite_function_p which was originally done for pure/const detection
> and  is implemented by looking at loop nest if all loops are known to be
> finite and also by checking for irreducible loops.

I see it doesn't do anything if mark_dfs_back_edges returns false, so it
will claim the function is finite even when it calls a non-finite function?
So I assume this is local analysis only and call edges will be handled
elsewhere?

I found another similar compute, fill_always_executed_in in LIM
(that considers all non-PURE calls as eventually looping, relying
solely on gimple_has_side_effects here).

In the end I want to have this on a stmt granularity (stmts before
calls are OK, stmts after not).

I guess greedily walking loop blocks along edges or walking in RPO oder
and tracking whether there's no possible exit on the way to X would be
the way to go.