<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 8, 2016 at 9:55 AM, Hal Finkel via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">----- Original Message -----<br>
> From: "Mehdi Amini via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
> To: "Rafael Espíndola" <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>><br>
> Cc: "llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>, "cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
> Sent: Tuesday, March 8, 2016 11:40:47 AM<br>
> Subject: Re: [cfe-dev] [llvm-dev] llvm and clang are getting slower<br>
><br>
> Hi Rafael,<br>
><br>
> CC: cfe-dev<br>
><br>
> Thanks for sharing. We also noticed this internally, and I know that<br>
> Bruno and Chris are working on some infrastructure and tooling to<br>
> help tracking closely compile time regressions.<br>
><br>
> We had this conversation internally about the tradeoff between<br>
> compile-time and runtime performance, and I planned to bring-up the<br>
> topic on the list in the coming months, this looks like a good<br>
> occasion to plant the seed. Apparently in the past (years/decade<br>
> ago?) the project was very conservative on adding any optimizations<br>
> that would impact compile time, however there is no explicit policy<br>
> (that I know of) to address this tradeoff.<br>
> The closest I could find would be what Chandler wrote in:<br>
> <a href="http://reviews.llvm.org/D12826" rel="noreferrer" target="_blank">http://reviews.llvm.org/D12826</a> ; for instance for O2 he stated that<br>
> "if an optimization increases compile time by 5% or increases code<br>
> size by 5% for a particular benchmark, that benchmark should also be<br>
> one which sees a 5% runtime improvement".<br>
><br>
> My hope is that with better tooling for tracking compile time in the<br>
> future, we'll reach a state where we'll be able to consider<br>
> "breaking" the compile-time regression test as important as breaking<br>
> any test: i.e. the offending commit should be reverted unless it has<br>
> been shown to significantly (hand wavy...) improve the runtime<br>
> performance.<br>
><br>
> <troll><br>
> With the current trend, the Polly developers don't have to worry<br>
> about improving their compile time, we'll catch up with them ;)<br>
> </troll><br>
<br>
</div></div>My two largest pet peeves in this area are:<br></blockquote><div><br></div><div>I think you hit on something that i would expand on:<br><br></div><div>We don't hold the line very well on adding little things to passes and analysis over time.</div><div>We add 1000 little walkers and pattern matchers to try to get better code, and then often add knobs to try to control their overall compile time.</div><div>At some point, these all add up. You end up with the same flat profile if you do this everywhere, but your compiler gets slower.</div><div>At some point, someone has to stop and say "well, wait a minute, are there better algorithms or architecture we should be using to do this", and either do it, or not let it get worse :) I'd suggest, in most cases, we know better ways to do almost all of these things.</div><div><br></div><div>Don't get me wrong, i don't believe there is any theoretically pure way to do everything that we can just implement and never have to tweak. But it's a continuum, and at some point you have to stop and re-evaluate whether the current approach is really the right one if you have to have a billion little things to it get what you want.</div><div>We often don't do that.</div><div>We go *very* far down the path of a billion tweaks and adding knobs, and what we have now, compile time wise, is what you get when you do that :)</div><div>I suspect this is because we don't really want to try to force work on people who are just trying to get crap done. We're all good contributors trying to do the right thing, and saying no often seems obstructionist, etc.</div><div>The problem is at some point you end up with the tragedy of the commons.</div><div><br></div><div>(also, not everything in the compiler has to catch every case to get good code)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
1. We often use functions from ValueTracking (to get known bits, the number of sign bits, etc.) as through they're low cost. They're not really low cost. The problem is that they *should* be. These functions do bottom-up walks, and could cache their results. Instead, they do a limited walk and recompute everything each time. This is expensive, and a significant amount of our InstCombine time goes to ValueTracking, and that shouldn't be the case. The more we add to InstCombine (and related passes), and the more we run InstCombine, the worse this gets. On the other hand, fixing this will help both compile time and code quality.<br></blockquote><div><br></div><div>(LVI is another great example. Fun fact: If you ask for value info for everything, it's no longer lazy ....) </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Furthermore, BasicAA has the same problem.<br>
<br>
2. We have "cleanup" passes in the pipeline, such as those that run after loop unrolling and/or vectorization, that run regardless of whether the preceding pass actually did anything. We've been adding more of these, and they catch important use cases, but we need a better infrastructure for this (either with the new pass manager or otherwise).<br>
<br>
Also, I'm very hopeful that as our new MemorySSA and GVN improvements materialize, we'll see large compile-time improvements from that work. We spend a huge amount of time in GVN computing memory-dependency information (the dwarfs the time spent by GVN doing actual value numbering work by an order of magnitude or more).<br></blockquote><div><br></div><div>I'm a working on it ;)</div><div> </div></div></div></div>