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

[Daniel Berlin via llvm-commits]

On Mon, Apr 11, 2016 at 10:18 AM, Teresa Johnson <tejohnson at google.com>
wrote:

> tejohnson added a comment.
>
> In http://reviews.llvm.org/D15537#397257, @davidxl wrote:
>
> > yes -- MemSSA will get there.  Short term workaround might also be
> needed :)
>
>
> I think we need a stopgap fix for this non-linear compile time issue.


Again, my main concern is that literally every other "stopgap" fix around
memory optimization issues has not been a stopgap.
There is no other way to put it.
These things have compounded *very* badly over time.
I'm not approving yet another compile time knob for another N^2/N^3 pass
that we know how to fix the right way.
(In part because i am the one who ends up having to fix it later :P)

We have to hold the line somewhere. This is where i am holding it. If you
want to get someone else to approve it, i won't stand in the way.


> I don't think waiting until it is reimplemented to use MemorySSA is a good
> strategy given the extreme compile time issues,


Which, for the most part, only occur in new build modes or very artificial
code.


> and I can't even find a switch to disable this pass.
>

This is definitely a problem.  Honestly, at this point, i would rather see
us disable the pass entirely with a large number of stores than add yet
another knob to control other things (like how many instructions it visits).

>
> BTW, the author had provided a test case on the mailing list (there are
> two threads for this patch):
>
>
> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160201/330335.html


If you look at the testcase, it is *very* artificial :)



>
>
> http://reviews.llvm.org/D15537
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160411/f449b2c6/attachment.html>