[PATCH] D35664: [SCEV] Limit max size of AddRecExpr during evolving

[Max Kazantsev via Phabricator via llvm-commits]

mkazantsev added a comment.

In https://reviews.llvm.org/D35664#817651, @sanjoy wrote:

> In https://reviews.llvm.org/D35664#817431, @mkazantsev wrote:
>
> > Hi Sanjoy,
> >
> > Investigating the impact of thresholds may be an interesting idea indeed. But it is not clear where should we measure them. This patch came from evaluation of bugs 33753 and 33494 (and actually is a fix for the 1st one and some subset of tests of the latter). The problem is that the impact of these parameters can differ dramatically on real workloads and fuzzed tests of special forms. For example, some of the tests from bug 33494 pass with only limit for AddRecs set, and others also need reduction of Arith limit to pass in reasonable time. The values of those limits are chosen absolutely randomly, though, and it is not clear what we should use as a reference when chosing their values.
>
>
> This is what I mean -- let's say in "real" workloads (for some fuzzy definition of "real"), `AddRec->getNumOperands() + OtherAddRec->getNumOperands() - 1` is 18 roughly 30% of the time, and is never more than 20.  In such a universe, we've picked a too low value for `MaxAddRecSize` -- we should have set it to 20.  In other words, I'm interested in the code-quality impact of these thresholds on real world code.  Since "real world code" means different things to different folks, having a somewhat generic method of deriving these limits will be useful.


I've filed the bug https://bugs.llvm.org/show_bug.cgi?id=33901 to keep track on this task. I think some other limits, such as arithmetic depth limit, also may be re-adjusted.


https://reviews.llvm.org/D35664