[PATCH] D44814: [CodeGenPrepare] Split huge basic blocks for faster compilation.

[Michael Zolotukhin via llvm-commits]

> On Apr 2, 2018, at 7:40 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
> 
> 
> 
> On Mon, Apr 2, 2018 at 5:36 PM, Michael Zolotukhin <mzolotukhin at apple.com <mailto:mzolotukhin at apple.com>> wrote:
> 
> 
>> On Apr 2, 2018, at 4:43 PM, Daniel Berlin <dberlin at dberlin.org <mailto:dberlin at dberlin.org>> wrote:
>> 
>> On Mon, Apr 2, 2018 at 3:50 PM, Michael Zolotukhin via Phabricator <reviews at reviews.llvm.org <mailto:reviews at reviews.llvm.org>> wrote:
>> mzolotukhin added a comment.
>> 
>> > 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.
>> >  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?
>> 
>> 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. 
>> 
>> That's the goal of performance testing, design review, etc.
>> 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".
>> 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.
>> 
> 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”.
> 
> 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
> 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
> 2. This is similar to how we handle just about all other workarounds - the user can disable the pass individually.
> 
> 
> 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. 
> If we aren't doing that well enough, this being the default won't help that, and will make that a lot worse.
> 
> Looking at GCC data, the number of severe compile time bugs per release is O(0).
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):
1) Don’t do any of this (not even under a flag)
2) Add this under a flag and disable it by default
3) Add this under a flag and enable it by default with a relatively high threshold

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)?

Thanks,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180403/0779d1c1/attachment.html>