<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 2, 2018, at 7:40 PM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org" class="">dberlin@dberlin.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Mon, Apr 2, 2018 at 5:36 PM, Michael Zolotukhin<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:mzolotukhin@apple.com" target="_blank" class="">mzolotukhin@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word; line-break: after-white-space;" class=""><br class=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class="">On Apr 2, 2018, at 4:43 PM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org" target="_blank" class="">dberlin@dberlin.org</a>> wrote:</div><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 2, 2018 at 3:50 PM, Michael Zolotukhin via Phabricator<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:reviews@reviews.llvm.org" target="_blank" class="">reviews@reviews.llvm.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">mzolotukhin added a comment.<br class=""><span class=""><br class="">> 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 class="">> 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 class=""><br class=""></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.<span class="Apple-converted-space"> </span></blockquote><div class=""><br class=""></div><div class="">That's the goal of performance testing, design review, etc.</div><div class="">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 class="">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 class=""><br class=""></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 class=""><br class=""></div><div class="">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 class="">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 class="">2. This is similar to how we handle just about all other workarounds - the user can disable the pass individually.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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 class="">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 class=""><br class=""></div><div class="">Looking at GCC data, the number of severe compile time bugs per release is O(0).</div></div></div></blockquote>Ok, I anticipated that point, the question was mostly about what we decide to value more. So far, I can see following options (please correct me if I miss something):</div><div>1) Don’t do any of this (not even under a flag)</div><div>2) Add this under a flag and disable it by default</div><div>3) Add this under a flag and enable it by default with a relatively high threshold</div><div><br class=""></div><div>I see that people don’t like option (3). Would it make sense to pursue (2), or there is no interest in this whatsoever, and we should stick to (1)?</div><div><br class=""></div><div>Thanks,</div><div>Michael</div></body></html>