<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 2, 2018 at 3:50 PM, Michael Zolotukhin via Phabricator <span dir="ltr"><<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">mzolotukhin added a comment.<br>
<span class=""><br>
> I don't know how I feel about this patch. It looks like it's papering over a huge problem, which is basically the fact that some passes down the road are either quadratic or linear with large constant factor.<br>
>  If we have examples of the broken passes, maybe we should consider whether it's feasible to fix them instead of applying this hack here?<br>
<br>
</span>We do have examples of such passes, and we should fix them, I agree. However, I don't consider this patch as a fix for them. The purpose of this patch is to prevent compiler hangs in future - even when we fix the known issues, there is no guarantee that there are no more places like them. </blockquote><div><br></div><div>That's the goal of performance testing, design review, etc.</div><div>What guarantees you have no more places like them is precisely "don't use algorithms that require random limits in random places to function efficiently, unless it absolutely cannot be avoided".</div><div>Most of the current time problems can be avoided, and if we'd stop hacking around them with random limits, then yes, you would guarantee there are no more places like them.</div><div><br></div><div><br></div><div>Questions:<br>1. How do you expect any user to ever report these issues if they don't see them?<br> 2. How does one make sure they aren't making compile time worse with his installed?</div><div>(IE do you expect them to turn this off, taking into account, or what?<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When we specifically want to look for such problematic spots, we can always set the option to -1, but by default it will just save us from "compiler hangs" (at least, from those coming from backend).<br>
<br></blockquote><div><br></div><div>Sorry, this doesn't' make a lot of sense to me to ever be on by default.    </div><div><br></div><div>In fact, i probably would have gone the other way.</div><div>If we asserted that compilation scaled linearly with number of instructions, we'd probably have fixed most of the problems by now just from annoyance:)</div></div></div></div>