[PATCH] D30350: [LSR] Add a cap for reassociation of AllFixupsOutsideLoop type LSRUse to protect compile time

[Wei Mi via llvm-commits]

On Sun, Mar 26, 2017 at 5:33 PM, Wei Mi <wmi at google.com> wrote:
> On Sat, Mar 25, 2017 at 10:36 PM, Sanjoy Das via Phabricator
> <reviews at reviews.llvm.org> wrote:
>> sanjoy added a comment.
>>
>> Hi Wei,
>>
>> If this indeed is a problem with `ScalarEvolution::getZeroExtendExpr` then you should be able to write a `.ll` file that triggers the exponential behavior on `-analyze -scalar-evolution`.  Do you mind giving writing such a test case (as a first step) a shot?
>
> Sanjoy, good suggestion. I will write such a testcase.
>
> Wei.

I spent quite some time to write the test because it is actually very
tricky to trigger the non-linear behavior. Mostly the non-linear
behavior will not be triggered because UniqueSCEVs can cache repeated
requests for getZeroExtendExpr. But when ZAdd == OperandExtendedAdd
and AR is set to SCEV::FlagNW,  the newly created SCEV is not
SCEVZeroExtendExpr + Original Op and UniqueSCEVs cache will not take
effect.

I didn't write a .ll test successfully in the end, because I have no
way to trigger getZeroExtendExpr while maintaining the nsw flag on the
SCEV exprs (This is needed for ZAdd == OperandExtendedAdd). but I
created a test in unittests/Analysis/ScalarEvolutionTest.cpp which I
attached.
Execution of ./unittests/Analysis/AnalysisTests will execute > 4min in
debug mode. I can increase the compile time sharply by continuing to
duplicating the code pattern in ScalarEvolutionTest.cpp.

>
>>
>>
>> Repository:
>>   rL LLVM
>>
>> https://reviews.llvm.org/D30350
>>
>>
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.patch
Type: application/octet-stream
Size: 6860 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170328/4687c0ed/attachment.obj>