For a loop body with complicated exit condition evaluation, constant evolving may run out of stack on some platforms, such as Windows. Need to limit the recursion depth.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Rather than a command line option, can you find the recursion limit hit by the LLVM test suite (and SPEC if you have access) and set the limit a bit higher with sufficient comments?
sure, I will schedule that test this night to see whether we need to raise that limit.
Please upload with context?
Did you try to see how much work it would be to avoid recursion altogether (and do an iterative scheme instead)?
iterative one is quite straight-forward but I don't see whether it's necessary. 'getConstantEvolvingPHI' is used in 'computeExitCountExhaustively' to evolve loop symbolically to check trip count in brute-force manner. I hardly to see it's widely applied. Ofc, let's check the statistics to see whether that's reasonable.
In addition, if ' getConstantEvolvingPHI' is re-written in iterative scheme, 'EvaluateExpression' needs to be re-written too as the later is predicated from the former and may push the out-of-stack into the later.
I collected the maximum depth of 'getConstantEvolvingPHIOperands' when it returns successfully or otherwise. Here is the statistics collected on SingleSource, MultiSource, and External (spec2000 and spec2006).
- when 'getConstantEvolvingPHIOperands' returns null
MAX-DEPTH-PER-CUNIT | NUM-OF-CUNITS |
---|---|
0 | 103 |
1 | 169 |
2 | 653 |
3 | 187 |
4 | 145 |
5 | 76 |
6 | 65 |
7 | 18 |
8 | 94 |
9 | 5 |
10 | 12 |
11 | 10 |
12 | 5 |
13 | 3 |
- when 'getConstantEvolvingPHIOperands' return non-null
MAX-DEPTH-PER-CUNIT | NUM-OF-CUNITS |
---|---|
0 | 159 |
1 | 323 |
2 | 502 |
3 | 218 |
4 | 546 |
5 | 167 |
6 | 100 |
7 | 49 |
8 | 432 |
9 | 46 |
10 | 29 |
11 | 10 |
12 | 4 |
13 | 10 |
16 | 1 |
17 | 3 |
18 | 1 |
19 | 1 |
It sounds to me that 32 is a reasonable choice.
Sounds good to me. I don't think you need to add a command line flag.
FWIW, I'm also in favor of moving to iterative solutions, although that does not always eliminate the need for arbitrary thresholds to bound the compute time.
I'm strongly against unbounded recursion anywhere in the compiler.
Sure, I will look into the rewriting them later as we need to rewrite both getConstantEvolvingPHIOperands and EvaluateExpression. The command line option is still preferred as platforms targetting for very different target may found it's necessary to goes deep due to aggressive inlining and other code bloating optimizations. Thanks for the review.