krememek added a comment.
In http://reviews.llvm.org/D12358#234975, @krememek wrote:
>
>
>
> 1. We need to consult the number of times a loop has been executed to
> determine when to apply this widening. We can look at the basic block
> counts, which are already used to cull off too many loop iterations.
On closer inspection, this is actually already in the patch:
BldCtx.blockCount() == AMgr.options.maxBlockVisitOnPath - 1
I do wonder if nested loops will cause a problem here, however. If a loop is
nested, `blockCount()` could already be the same as `maxBlockVisitOnPath() `
because of the outer loop. For example:
for (int i = 0; i < 3; i++) {
for (int j = 0; j < 2; j++) { ... }
}
On the second iteration of the outer loop, but the first iteration of the inner
loop within that second outer loop iteration, the block count for the body of
the nested loop will already be 2. The analyzer will prune paths, regardless
of this loop widening heuristic. I don't think the suggested patch actually
helps with this case because the block count gets exhausted. We may need a way
to enhance the accounting of block counts when taking into account heuristics
for loops.
http://reviews.llvm.org/D12358
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
