<div dir="ltr"><div>2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Changing a header file somewhere and having to spend 10 minutes waiting for a build leads to a lot of wasted developer time.<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?</div></div></blockquote><div></div></div><div><br></div><div>Splitting ADT just based on tablegen usage seems dubious to me. If we need to go this route, I'd replace as many uses of ADT data structure with STL ones to begin with to reduce the surface.</div><div><br></div><div><br></div><div class="gmail_extra"><div class="gmail_quote">2017-05-28 8:25 GMT-07:00 Krzysztof Parzyszek via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 5/26/2017 7:59 PM, Zachary Turner via llvm-dev wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
It's that TableGen depends on Support, so if you change one file in<br>
support, support gets recompiled into a new static archive, which<br>
triggers a rerun of tablegen on all the tablegen inputs, which is<br>
extremely slow.<br>
</blockquote>
<br></span>
What exactly is extremely slow? In my experience TableGen itself takes a negligible amount of time compared to the rest of the build. This is particularly true in cases when something in Support or ADT is modified, as this usually triggers recompilation of large parts of LLVM.<br></blockquote><div><br></div><div>Tablegen built in debug is really slow though, I remember an out-of-tree backend where running llvm-tblgen was taking up to 5 min per file!<div>The CMake option LLVM_OPTIMIZED_TABLEGEN helps a lot with this. Otherwise LLVM_TABLEGEN is even more efficient, but it's a double-edged sword.</div><div><br></div><div>But we could also use the diff-and-copy approach not on the tablegen output but on the llvm-tblgen binary itself, that way we wouldn't re-run it when it does not change itself (I'm not sure why CMake does not use this strategy by default for any file including .o and .a?).</div></div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div></div></div></div>