<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 2, 2018 at 5:36 PM, Michael Zolotukhin <span dir="ltr"><<a href="mailto:mzolotukhin@apple.com" target="_blank">mzolotukhin@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><span class=""><br><blockquote type="cite"><div>On Apr 2, 2018, at 4:43 PM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>> wrote:</div><div><div dir="ltr"><br><div class="gmail_extra"><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><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></div></div></div></blockquote></span>I don’t argue that it’s a workaround, and in ideal world we would never need anything like this. In practice we have reviews, performance testing, etc, but non-linear algorithms still slip through. If we fix all known problems now (and we absolutely should), I still don’t see what will prevent a user from discovering a next place tomorrow. And for the user that would be “this compiler hangs”.</div></div></blockquote><div><br></div><div>Yes, there is never any absolute. To me, that doesn't justify doing this by default, which has a *lot* of downsides.  Certainly, i see the upside for a user, but</div><div>1. Leaving it off by default still gives a workaround to the user if needed, without any of the downsides of having it by default</div><div>2. This is similar to how we handle just about all other workarounds - the user can disable the pass individually.</div><div><br></div><div><br></div><div>If we are doing our job well enough, the number of users that should see hangs should be ridiculously small, and it should get fixed in the next release. </div><div>If we aren't doing that well enough, this being the default won't help that, and will make that a lot worse.</div><div><br></div><div>Looking at GCC data, the number of severe compile time bugs per release is O(0).</div><div><br></div></div><br></div></div>