<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Jan 14, 2019 at 6:17 PM Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</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"><div dir="ltr">The *specific* desire is to get methods from Support and ADT to work well in debug builds. So not sure building those things with O3 helps.<div><br></div><div>I really don't understand the tension here.</div><div><br></div><div>Fundamentally, I think we need to give up on debug builds have super predictable build-time performance. IMO, that includes tablegen. I'm happy to have workarounds like building an optimized tablegen binary, but I'm not sure its worth the complexity that it sounsd like that entails.</div><div><br></div><div>(Separately, I really wish Ninja and/or CMake had *good* models for a host build vs. a target build so that it was easy and reliable to get optimized host utilities built as well as unoptimized target binaries, but that seems to be a real problem in their current design and I'm not suggesting we wait for that to fix any of this.)</div></div></blockquote><div><br></div><div>(That's a CMake issue. See <a href="https://reviews.llvm.org/D56577">https://reviews.llvm.org/D56577</a> llvm/trunk/utils/gn/secondary/BUILD.gn line 15 for how you say "build this target, but with a toolchain targeting Android instead of the host system" in GN, and GN just writes ninja files too – so this is very possible on a Ninja level.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 14, 2019 at 3:11 PM Nico Weber <<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</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>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-m_2349118411531166989gmail-m_-7259398525340591195gmail_attr">On Mon, Jan 14, 2019 at 4:52 PM Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">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>
</blockquote></div>
</blockquote></div></div></div></div>