https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113994
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #9)
> Ick, it's via iv_analysis_loop_init used from doloop and unroll.
In that context I'll note that if it is doloop itself that does the DF
live query then it's doloops fault to not operate within the constraints
of iv_analysis_loop_init. It might be possible to add a flag to
iv_analysis_loop_init to elide its df_analyze stuff and instead have the
caller do a function-wide DF analysis.
I see doloop_optimize_loops does
if (optimize == 1)
{
df_live_add_problem ();
df_live_set_all_dirty ();
}
for (auto loop : loops_list (cfun, 0))
doloop_optimize (loop);
but never calls df_analyze. I'm not actually sure what happens if you
then do df_analyze_loops, whether that scraps all but the loop BB
info computed? Anyway, I don't think that simply adding another problem
"around" iv_analysis_loop_init works as we can see here. If
iv_analysis_loop_init were to compute liveness it would see that it needs
more that just the loop body blocks.
Also note that my patch while it might work in most cases, isn't fool-proof.
The actual use might be in the very last BB of the function (very unlikely
for CC, of course). Doing an analysis of all reachable blocks perverts
the use of df_analyze_loop.
So. It looks all broken design to me (in doloop).
