<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 7 Jul 2017, at 17:12, David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I'm /guessing/ this is probably pretty normal - but likely the best solution would be to get down to granularity of 1 commit in each of those ranges, to see if it's really justified that the change causes so much recompilation (ie: do all the things that got compiled really depend on the modified file)<br class=""><br class="">Some of this might be tablegen recompiling - but I /think/ that ninja has some support/seems to do the right thing when the resulting tablegen binary isn't different from previously (or maybe when it doesn't generate different output - this would be better) & doesn't cause everything to rebuild (you'll notice Ninja sometimes starts with a very high estimate (1000+) of targets to rebuild, but the estimate is adjusted down to only a couple of hundred in many cases probably due to this.</div></div></blockquote><div><br class=""></div><div>I can confirm that tablegen-erated files do the right thing and that it's based on the output of tablegen. Our cmake scripts do it by having llvm-tblgen write to a temporary file and then use 'cmake -E copy_if_different' to update the real one when necessary. Once ninja has run the copy_if_different command it re-checks the dependencies and culls the ones it doesn't need.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Jul 7, 2017 at 6:47 AM Nemanja Ivanovic via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class=""><div class=""><div class="">Hi everyone,<br class=""></div>I have felt for quite some time that during my regular LLVM workflow, CMake recompiles a lot of files after I update to the latest ToT (which I do more than once per week). Of course, this wasn't really based on any real data, just felt like every time I update (even if it's a day or two later), we end up recompiling everything. For a while I assumed that patches touch a few headers that are used all over the place or something like that, but this was happening with what seems like unexpected frequency.<br class=""><br class=""></div>So what I've done is do a few update/rebuild cycles for revisions that are 200 apart, then 100, then 50, then 25. And it seems that quite commonly, we recompile more than 50% of the source with just a few landed revisions. I've included the numbers below (and I do realize that this is a fairly small sample).<br class=""><br class=""></div><div class="">If this seems reasonable to most of the community, so be it - I work on a large server that chews through this stuff pretty quickly so I can certainly live with it. On the other hand, if this seems way higher than what you expect, it could very well be that something is wrong in my setup and I'd appreciate some pointers about how to go about investigating this. Finally, if others are seeing this and we as a community do feel that something can/should be done about this (although I don't know what that might be), perhaps we can start that discussion.<br class=""><br class=""></div><div class="">Setup: CMake with -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -G Ninja<br class=""></div><div class=""><br class="">The numbers here are the total numbers of targets ninja reports as having rebuilt. Ninja is invoked only `-j <N>` for parameters (i.e. not check-all or any specific targets).<br class=""><br class=""><span style="font-family:monospace,monospace" class="">RevFrm, RevTo, NumNinjaObjsRebuilt<br class="">300000, 300200, 2957<br class="">300200, 300400, 2692<br class="">300400, 300600, 3001<br class="">300600, 300800, 2877<br class="">300800, 301000, 3003<br class="">301000, 301200, 2750<br class="">301200, 301400, 2579<br class="">301400, 301600, 2709<br class="">301600, 301700, 2325<br class="">301700, 301800, 2357<br class="">301800, 301900, 2667<br class="">301900, 302000, 2466<br class="">302000, 302100, 2499<br class="">302100, 302200, 2063<br class="">302200, 302250, 2884<br class="">302250, 302300, 2007<br class="">302300, 302350, 2209<br class="">302350, 302400, 737<br class="">302400, 302450, 2398<br class="">302450, 302500, 2856<br class="">302500, 302550, 2090<br class="">302550, 302600, 2866<br class="">302600, 302625, 1786<br class="">302625, 302650, 1966<br class="">302650, 302675, 1583<br class="">302675, 302700, 307<br class="">302700, 302725, 2246</span><br class=""></div></div>
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>