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.
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
- when 'getConstantEvolvingPHIOperands' return non-null
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.