On Sat, Aug 12, 2017 at 9:55 AM, Christopher Li <sparse@xxxxxxxxxxx> wrote: > On Sat, Aug 12, 2017 at 8:55 AM, Luc Van Oostenryck > <luc.vanoostenryck@xxxxxxxxx> wrote: >> 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+). There is also the other way to do it. Every time the CFG changed, set a changed flag. Stop CSE if there is no more change reached. It should detect the problem that currently we think there is opportunity to optimize, but turn out there is not. If we keep repeating this loop, that is a bug, we need to fix it. Another way to look at it is, the model should be more if we are sure there is change can be make, then we go do the change. Current CSE scanning all instructions looking for oppertuniity is actually not very optimal. Chris -- 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
