[llvm] r294181 - [SCEV] limit recursion depth and operands number in getAddExpr

[Sanjoy Das via llvm-commits]

Let's revert for now then?  Once we figure out some other way to test
this, we'll re-land.

On Feb 6, 2017 11:27, "Chandler Carruth via llvm-commits"
<llvm-commits at lists.llvm.org> wrote:
>
> On Mon, Feb 6, 2017 at 11:22 AM Chandler Carruth <chandlerc at gmail.com> wrote:
>>
>> This adds a unittest that *with optimizations* takes over 20 seconds to run. That seems excessive.
>
>
> Specifically...
>
>>
>> On Mon, Feb 6, 2017 at 4:49 AM Daniil Fukalov via llvm-commits <llvm-commits at lists.llvm.org> wrote:
>>>
>>> +static cl::opt<unsigned>
>>> +    MaxAddExprDepth("scalar-evolution-max-addexpr-depth", cl::Hidden,
>>> +                    cl::desc("Maximum depth of recursive AddExpr"),
>>> +                    cl::init(32));
>
>
> The recursion limit is 32...
>
>
>>>
>>> +  for (int i = 0; i < 1000; i++) {
>>> +    Mul1 = BinaryOperator::CreateMul(Add2, Add1, "", EntryBB);
>>> +    Add1 = Add2;
>>> +    Add2 = BinaryOperator::CreateAdd(Mul1, Add1, "", EntryBB);
>>> +  }
>
>
> And the test builds IR with 1000 adds and 1000 muls. It isn't clear at all that this is a reasonable way to unittest something.
>
> What's worse, when I make this 1000 be 10 instead, nothing fails despite transitioning from above to below the recursion limit above. So I'm not really sure what this is testing at all?

I don't think it is supposed to fail that way.  The buggy behavior is
to, with an infinite (say) recursion limit, take an exponential amount
of time to construct the SCEV expression.

-- Sanjoy

>
> Anyways, this is making each of my test runs over 50% slower (18s -> 26s) and I suspect several build bots are similarly impacted.
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>