[PATCH] D22639: Add flag to PassManagerBuilder to disable GVN Hoist Pass.

[Daniel Berlin via llvm-commits]

So, on the substantive side, this test case takes a reasonable amount of
time with -print-memoryssa -analyze, so it's in GVNHoist's use of MemorySSA
(it looks like it's making N^3 number of calls or something), and not
MemorySSA itself.

It does make me realize we can make the initial use optimization even
faster without taking a ton of memory though, and i'll go fix that. Someone
needs to look at GVNHoist in the meanwhile :)


On Thu, Jul 21, 2016 at 12:50 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

> +george
>
> On Thu, Jul 21, 2016 at 12:49 PM, Daniel Berlin <dberlin at dberlin.org>
> wrote:
>
>>
>>
>> On Thu, Jul 21, 2016 at 12:43 PM, Benjamin Kramer <benny.kra at gmail.com>
>> wrote:
>>
>>> bkramer added a subscriber: bkramer.
>>> bkramer added a comment.
>>>
>>> The problem is not a Halide test but a scalability issue in MemorySSA
>>> that's making Halide unusable, consuming gigabytes of memory and taking
>>> forever.
>>
>>
>>
>> Personally, I don't think the GVNHoist pass is ready for prime time yet
>>> and needs more testing, like we did for other passes that were first
>>> rigorously tested under a flag before being enabled by default. Going
>>> directly from zero to default with a major new optimization infrastructure
>>> (MemSSA) is a recipe for disaster.
>>>
>>
>> I agree that GVNHoist probably should not be on by default yet regardless
>> of anything else.
>>
>> George recently (IE this week) replaced the walker in MemorySSA because
>> we've known from the beginning that there were significant scaling issues
>> in the original impl (it could use N^2 memory and time easily with the
>> caching scheme it used) .
>>
>> It's likely you just hit one of these cases.
>>
>>
>>> Sadly the test case is fairly large and being a compile time regression
>>> reduction is difficult, I believe Alina is working on that.
>>>
>>> Can you send me the testcase, even if large?
>>
>> Alternatively, i'm curious if it's still an issue with George's latest
>> walker commit.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160721/44605f09/attachment.html>