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

[Michael Zolotukhin via llvm-commits]

> 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 <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”.

> 
> Questions:
> 1. How do you expect any user to ever report these issues if they don't see them?
I expect it stays on by default except for when people are actively looking for such kind of problems. In some sense, this would shift testing responsibility from LLVM users to LLVM developers. Also, the issues will still be detectable, they just won’t be complete hangs.
>  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?
We could turn it off for the testing (e.g. if a new pass is being added). We might also think about adding a bot (or turn it off on the bot that runs testing with expensive checks).
>  
> 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:)

Again, I agree that it’s a workaround and not a solution, real problems still need to be fixed (I and many others are working on that too!). But this does help users in situations when they hit something we haven’t had time to fix yet.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180402/be70a2bc/attachment.html>