<div dir="ltr"><div dir="ltr"><div>I agree that shelling out to `cmake --build` as a build step is pretty ugly.</div><div><br></div><div>It seems kind of simpler to me to just always build Support and TableGen with O3 always, even in debug builds. Most people don't debug code in Support and TableGen, and there could be a disable switch for those that do. That gives you a fast(er) debug build without building any files twice. Is that something CMake can do? If so, is this something that was considered?<br></div><div><br></div><div>(It's not implemented, but in the GN build it's in theory doable to have a release toolchain and always use that for tablegen, that way you have the same effect, but the duplicate build of tablegen is just part of the regular build. But I figured the "always O3 for lib/Support and lib/TableGen" approach would be nicer there too. Since I always do Release builds like Reid and just switch to Debug when I need it, it wasn't a priority for me to think too much about this though.)</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 14, 2019 at 4:52 PM Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Fri, Jan 11, 2019 at 11:18 AM Davide Italiano via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
After yet another round of discussions, the plan is that of trying not<br>
to slap another attribute on the members, instead going for making<br>
OPTIMIZED_TLBGEN the default and removing always_inline.<br>
I'll do some testing locally (for the Ninja and the Xcode build<br>
generator). Pawel volunteered to take a look at the Visual Studio<br>
situation.<br>
I assume this is going to be the final plan we'll deploy unless<br>
somebody comes with any fundamental objections or there are technical<br>
hurdles down the road.<br></blockquote><div><br></div><div>So, personally I feel strongly that LLVM_OPTIMIZED_TABLEGEN should be off by default, since the it splits up the ninja build graph. We've also run into issues with it with VS: <a href="https://reviews.llvm.org/D54153" target="_blank">https://reviews.llvm.org/D54153</a>  Shelling out to `cmake --build` as part of a build action doesn't seem to work very well for many generators.</div><div><br></div><div>What actually blocks us from removing these always_inline attributes? When I read this thread, I didn't get the sense that debug build tablegen performance was actually important to anyone, but maybe I skimmed too much.</div><div><br></div><div>Maybe I am a luddite because I just build Release+Asserts with debug info enabled and then sprinkle `#pragma clang optimize off` around when I need to debug a particular source file. This keeps build & test fast enough except in the corner cases where a debugger is required.</div></div></div></div>
</blockquote></div>