[PATCH] D15537: limit the number of instructions per block examined by dead store elimination

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 25 09:50:15 PDT 2016


If folks are willing to actually commit to fixing this on a near-term
timeline (and it sounds like the answer was "yes"), i'm okay with this
patch.

If i've got that wrong, we really should explore other solutions (like
caching).


On Tue, Aug 23, 2016 at 4:47 PM, Philip Reames <listmail at philipreames.com>
wrote:

> FYI, I'm going to defer to Danny on the choice to move forward with this
> patch or an alternate.  I feel he's in the best position to assess the
> overall timeline for MemorySSA.
>
>
> On 08/23/2016 01:35 PM, Xinliang David Li wrote:
>
>> On Tue, Aug 23, 2016 at 1:20 PM, Daniel Berlin <dberlin at dberlin.org>
>> wrote:
>>
>>> While implementing caching is possible, I think we should avoid
>>>> reinventing the wheel in memorySSA, but to keep the fix as simple as
>>>> possible.  The new limit can be adjusted higher as its meaning has
>>>> changed.
>>>>
>>>
>>> I'd be more okay with your last argument if you were going to commit to
>>> rewriting this pass to MemorySSA.
>>> :)
>>>
>> Definitely committed -- no question about it :)  I don't think we have
>> any choice actually, but patches like this do allow buy us more time
>> to do so.
>>
>>
>> If we have no-one committed to moving the pass, and no plans to implement
>>> caching, i guess my answer is "hope that someone will move this to
>>> MemorySSA
>>> one day is not a strategy".
>>>
>> that is right.
>>
>> For this patch, I considered it high priority because there are so
>> many people got hit by the same issue again and again. The most recent
>> clang hanging problem in building chromium is a recent example.
>>
>> David
>>
>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160825/bda87331/attachment.html>


More information about the llvm-commits mailing list