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.
