<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, May 30, 2017 at 12:52 PM Bob Haarman via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u><div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif"><div>I would like to better understand how you came to conclude that the tablegen re-runs based on changes in Support are what's causing your build to be slow and what part specifically is taking all that time. I can do a clean release + assertions build of LLVM, Clang, compiler-rt and lld in about 5 minutes, plus 40 seconds to run cmake, on what I think is similar hardware to what Zach is using. If I swap Ptr += ret and Size -= Ret in raw_fd_ostream::write_impl so that Support changes, I can do an incremental build in about 10 seconds, including the regeneration of various .inc files. How do we get from there to 10 minutes for an incremental build?<br></div></div></div></blockquote><div><br>Which build system are you using?<br><br>On my build config (16 core/32 thread, 128GB RAM) it takes 47 user seconds to rebuild the clang binary after making the change you mentioned - with ninja and lld, host compiler is a recent release build of clang. Ninja reports building 377 things.<br><br>Comparatively, if I change something in lib/CodeGen/AsmPrinter, it builds 4 things and takes 19 user seconds. (most of that's probably the link step)<br><br>So it seems like rebuilding tablegen does rebuild quite a few things - but I'm not sure exactly which parts are avoidable and which parts aren't.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif"><div><br>---- On Fri, 26 May 2017 17:59:43 -0700 <b>Zachary Turner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></b> wrote ----<br></div></div></div><div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif"><div class="m_-6005341984375754785zmail_extra"><div><br></div><blockquote style="border-left:1px solid #cccccc;padding-left:6px;margin:0 0 0 5px"><div><div dir="ltr">It's that TableGen depends on Support, so if you change one file in support, support gets recompiled into a new static archive, which triggers a rerun of tablegen on all the tablegen inputs, which is extremely slow.<br></div><div><br></div><div><div dir="ltr">On Fri, May 26, 2017 at 5:56 PM Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<br></div><blockquote style="margin:0 0 0 0.8ex;border-left:1.0px rgb(204,204,204) solid;padding-left:1.0ex"><div><p><br></p><div><br></div><div>On 05/26/2017 07:47 PM, Zachary Turner       via llvm-dev wrote:<br></div><blockquote><div dir="ltr"><div>Changing a header file somewhere and having to         spend 10 minutes waiting for a build leads to a lot of wasted         developer time. <br></div><div><br></div><div>The real culprit here is tablegen.  Can we split support           and ADT into two - the parts that tablegen depends on and the           parts that it doesn't?<br></div></div></blockquote><div><br></div></div><div><div>What's the actual problem here? Is it that TableGen regenerates     different files and so we then need to rebuild all dependencies of     those files? Maybe we should use a diff-and-update approach (I     thought, however, that we already did that).<br></div><div> <br></div><div>  -Hal<br></div><div> <br></div></div></blockquote></div></div></blockquote></div><div><br></div></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>