http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56490
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
>From what I can see, the main problem is that on this testcase (and apparently
also on gcc/ada/par.adb) in a single toplevel compute_control_dep_chain call
(i.e. one with cur_chain_len == 0) we can end up with millions of nested
compute_control_dep_chain, and at least on the testcase from this PR all
unsuccessful (num_chains == 0 after the call).
The quick fix can be just to have a counter and return immediate once we reach
the counter (say 1000) during the nested invocations.
For something better, perhaps in addition to such limiting we could watch for
basic blocks on which we've already called compute_control_dep_chain, and if
that call has been unsuccesful previously, record the cur_chain_len at which it
has been called. If we call it on such a bb again at the same or higher
cur_chain_len level, we could assume it is likely going to fail again.
The reason why I'm saying likely is that there is the:
for (i = 0; i < cur_chain_len; i++)
{
edge e = (*cur_cd_chain)[i];
/* Cycle detected. */
if (e->src == bb)
return false;
}
loop and with different start of the cur_cd_chain perhaps it could succeed even
when it failed before.
