<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><br class=""><blockquote type="cite" class=""><div class="">On Jan 9, 2019, at 10:52 AM, Joel E. Denny <<a href="mailto:jdenny.ornl@gmail.com" class="">jdenny.ornl@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Jan 8, 2019 at 6:04 PM Chris Bieneman <<a href="mailto:chris.bieneman@me.com" class="">chris.bieneman@me.com</a>> wrote:<br class=""></div><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 style="overflow-wrap: break-word;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jan 8, 2019, at 2:44 PM, Joel E. Denny via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_-2296978515651679138Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Jan 8, 2019 at 5:14 PM David Greene <<a href="mailto:dag@cray.com" target="_blank" class="">dag@cray.com</a>> wrote:<br class=""></div><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;">"Joel E. Denny via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> writes:<br class=""><br class="">> Do other Clang developers find BUILD_SHARED_LIBS=True useful? Do you<br class="">> see the above failures? Should there be a bot to test that build<br class="">> configuration?<br class=""><br class="">I don't use BUILD_SHARED_LIBS=True</blockquote><div class=""><br class=""></div><div class="">One point I'd like to understand is why more people don't use it.  Were you not aware of it, or is it just not beneficial enough to you?  I was very happy to reduce a nearly 4-minute rebuild after a minor change to ~31 sec.  Especially when I have to do that repeatedly, that time difference can determine whether I decide to switch contexts or stay focused.<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">How much of that rebuild time is actually link time? I'd guess most.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes.  Even more so because I forgot I have ccache enabled.<br class=""></div><div class=""> </div><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 style="overflow-wrap: break-word;" class=""><div class=""><div class="">What linker are you using? ld64, lld and gold are all much faster than bfd, so the performance implications may be smaller to other people.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I just tried LLVM_USE_LINKER=gold and then lld, and lld gave me a better incremental build time, so I'll stick with it.</div><div class=""><br class=""></div><div class="">The aforementioned ~4 min shrank to ~35s.  However, BUILD_SHARED_LIBS=True shrank that to 3s!<br class=""></div><div class=""><br class=""></div><div class="">Continuing to use lld, when I disable ccache (or make a change ccache hasn't seen), it's ~40s and BUILD_SHARED_LIBS=True shrinks it to ~13s.<br class=""></div><div class=""><br class=""></div><div class="">The gap is certainly closing, but BUILD_SHARED_LIBS=True still seems appealing.<br class=""></div><div class=""> </div><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 style="overflow-wrap: break-word;" class=""><div class=""><div class="">Also, using `BUILD_SHARED_LIBS` has a significant impact on execution performance of the final binaries, which impacts test execution speed. So if you aren't struggling with link time, it can be overall better to generate faster loading binaries for the test suite.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Indeed, ninja check-clang grows from ~10 min to ~20 min when I use BUILD_SHARED_LIBS=True.  Either way, I'd switch contexts instead of waiting, so my development time wouldn't necessarily grow with the latter.<br class=""></div><div class=""><br class=""></div><div class="">Nevertheless, whether to use BUILD_SHARED_LIBS=True is definitely a harder choice to make now.</div><div class=""> </div><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 style="overflow-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><div class="">There are a lot of tradeoffs on performance, but I've strongly advocated that BUILD_SHARED_LIBS should never be used when building distributions for performance reasons, which means it is only really supported as a developer workflow.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Seems fine to me except that, if it is supported as a developer workflow, the broken tests are a problem.<br class=""></div><div class=""> </div><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 style="overflow-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><div class="">Additionally BUILD_SHARED_LIBS is problematic with some of LLVM's design patterns, like cl::opt's global registration, which can deter its usefulness.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Could you explain a little more, or point to a previous discussion?<br class=""></div></div></div></div></div></div></blockquote><div><br class=""></div><div>cl::opt options are generally globally scoped. When you define one, they are added to a global list of options. No two options can have the same name.</div><div><br class=""></div><div>When you link against a shared library, all the globals for that shared library become part of your binary. When you link against a static archive only the globals for any translation units that you need get pulled into your binary.</div><div><br class=""></div><div>In the past this has resulted in BUILD_SHARED_LIBS and LLVM_USE_LLVM_DYLIB causing duplicate options to be registered which results in a fatal error (see CommandLine.cpp, addLiteralOption).</div><div><br class=""></div><div>-Chris</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""> </div><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 style="overflow-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><div class="">Hope this helps explain why it is less widely used than you might have anticipated.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Definitely.  Thanks!</div><br class=""></div><div class="gmail_quote">Joel<div class=""> </div><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 style="overflow-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><div class="">-Chris</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""> </div><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;">but if that's a supported option, it<br class="">should be tested.<br class=""><br class="">This argument will, of course, lead to an explosion of builders, as the<br class="">set of combinations of cmake variables is very large.  It would be<br class="">useful to gather the various configurations people use and see if there<br class="">is a set of common-ish combinations that is small enough to regularly<br class="">test.<br class=""><br class="">We build with RTTI and exceptions enabled and I'll bet there are others<br class="">out there that do the same.  But AFAIK there are no bots testing those<br class="">options.<br class=""></blockquote><div class=""><br class=""></div><div class="">To reduce the configuration space, we could consider combining orthogonal options under a single builder.  That could make debugging some fails a little harder, but it might be worthwhile as it would provide more coverage with less builders.<br class=""></div><div class=""><br class=""></div><div class="">Thanks.<br class=""></div><div class=""><br class=""></div><div class="">Joel<br class=""></div><div class=""> </div><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;"><br class="">                             -David<br class=""><br class=""></blockquote></div></div>_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote></div><br class=""></body></html>