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

[Daniel Berlin via llvm-commits]

On Mon, Apr 2, 2018 at 5:36 PM, Michael Zolotukhin <mzolotukhin at apple.com>
wrote:

>
>
> On Apr 2, 2018, at 4:43 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
> On Mon, Apr 2, 2018 at 3:50 PM, Michael Zolotukhin via Phabricator <
> 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180402/b0a1c626/attachment.html>