Currently, sparse can enter in infinite loops.
The effect can be seen is the normal simplification/CSE
loops but the origin of the problem is not there
(it's some interaction between simplify_loads() and
unreachable code, at least for a good part of them).
On the other hand, on normal code, the number of
simplification/CSE cycle is fairly small: even in big,
complex functions, in 80% of cases only 1 or 2 cycles are
needed. The most extreme I found was 12 cycles and that's
an unique case (on a total of 172000+).
So, avoid to let sparse in infinite loop by stopping
the loop if the number of cycles becomes too high: 16.
Note: this solves all the 77 cases of inifinite loop I found.
Note: of course, this patch doesn't change the fact that
the generated IR is broken and that the root cause(s)
must be addressed.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx>
---
The patch is also available in the git repository at:
git://github.com/lucvoo/sparse.git avoid-infinite-loop--max-cse
cse.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/cse.c b/cse.c
index 17b3da01a..fa136c370 100644
--- a/cse.c
+++ b/cse.c
@@ -356,13 +356,17 @@ static struct instruction * try_to_cse(struct entrypoint *ep, struct instruction
return i1;
}
+#define MAX_CSE_CYCLES 16
void cleanup_and_cse(struct entrypoint *ep)
{
+ int max = MAX_CSE_CYCLES;
int i;
simplify_memops(ep);
repeat:
repeat_phase = 0;
+ if (--max == 0)
+ return;
clean_up_insns(ep);
if (repeat_phase & REPEAT_CFG_CLEANUP)
kill_unreachable_bbs(ep);
--
2.14.0
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
