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

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 2 16:43:19 PDT 2018


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.


Questions:
1. How do you expect any user to ever report these issues if they don't see
them?
 2. How does one make sure they aren't making compile time worse with his
installed?
(IE do you expect them to turn this off, taking into account, or what?


> 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).
>
>
Sorry, this doesn't' make a lot of sense to me to ever be on by default.

In fact, i probably would have gone the other way.
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:)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180402/3fc65faf/attachment.html>


More information about the llvm-commits mailing list