<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 11, 2018 at 8:52 PM, Mostyn Bramley-Moore <span dir="ltr"><<a href="mailto:mostynb@vewd.com" target="_blank">mostynb@vewd.com</a>></span> wrote:<br><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 class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Wed, Apr 11, 2018 at 7:53 PM, Kim Gräsman via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">See also: <a href="https://www.llvm.org/devmtg/2014-04/PDFs/Talks/Tenseconds.pdf" rel="noreferrer" target="_blank">https://www.llvm.org/devmtg/20<wbr>14-04/PDFs/Talks/Tenseconds.pd<wbr>f</a></blockquote><div><br></div></span><div>I CC'ed Andy in my initial post, but the email bounced.</div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I started experimenting with a unity build of an LLVM/Clang-sized<br>
proprietary project at my previous employer, and I found the basics<br>
easy to get going. The hard part was massaging the code base to avoid<br>
collisions, as indicated by the work by Mostyn & co.<br>
<br>
I left the job before I had a chance to fully evaluate it, but<br>
assuming I'd had something like `#pragma jumbo` to reduce the<br>
friction, it might have been easier to get more data for less effort.<br>
<br>
Mostyn/Daniel, do you have any gut feel/data on how much of the<br>
problem a #pragma would solve? I suppose there are still constructs<br>
that `#pragma jumbo` can't help with, that requires manual<br>
intervention?<br></blockquote><div><br></div></span><div>The best side-by-side comparison that we have at the moment are the two chromium patch sets I mentioned- the numbers there match my gut feeling that something like the JumboSupport proof-of-concept could save us about 80% of the effort to jumbo-ify Chromium code. </div><div><br></div><div>There are a few other constructs that cause trouble less often, which could be investigated later for diminishing returns. Automatically popping clang diagnostic warning pragma states is one that came up the other day. I think I have seen globally scoped typedefs in top-level source files cause trouble (but these are rare).</div><div><br></div><div>And there are of course some constructs that I don't think are feasible to try to fix automatically, eg symbols and macros leaked by library headers (which are intentionally leaky)- X11 and Windows headers are particularly bad. </div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also, Chromium is hardly a typical codebase, the little I've looked at<br>
it, it's *extremely* clean and consistent, so it might be interesting<br>
to try this on something else. Maybe LLVM itself would be an<br>
interesting candidate.<br></blockquote><div><br></div></span><div>I don't have much experience with CMake, but I see a few references to CMake unity build helpers on the web <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">(if anyone has tips, feel free to ping me off-list)</span>. If it would be useful I can try to put together a small experiment with a subset of LLVM or Clang.</div></div></div></div></blockquote><div> </div><div>I decided to take a look at the clangSema target, and see what kind of difference the JumboSupport PoC would make. Instead of digging into CMake, I just wrote some small shell scripts to build this target in the various modes.</div><div><br></div><div>Without JumboSupport, I had to rename a couple of static functions (isGlobalVar and getDepthAndIndex in a couple of places), and rename a struct (PartialSpecMatchResult) that was inside an anonymous namespace. Alternatively you could decide to refactor and share the same implementations. I also excluded two source files from the jumbo compilation unit, due to clashes caused by a file being intentionally #include'd multiple times (alternatively you could sprinkle some #undef's around to make this work).</div><div><br></div><div>With JumboSupport, instead of renaming the static functions I just moved them into anonymous namespaces, and excluded the same two source files which #include some .def files multiple times, for the same reasons as above. I did not need to do anything about the PartialSpecMatchResult structs since they were already inside anonymous namespaces (one of them was at least, I did not need to check the other).</div><div><br></div><div>Of these two patches, the JumboSupport version was easier to produce, and I believe would require less effort to review- there would be no debate about what to rename things, or whether or not the code should be refactored and how. I think that anonymous namespaces should generally be preferred over static functions, and JumboSupport makes anonymous namespaces even more useful- it makes them behave the way that many developers (incorrectly) assume that they work. </div><div><br></div><div>Note that we don't claim that jumbo builds make sense for all codebases, and I'm not sure if it would make sense for Clang/LLVM. But JumboSupport did appear to help in this tiny experiment.</div><div><br></div><div>-Mostyn.</div><div><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 class="gmail_extra"><div class="gmail_quote"><span class="gmail-HOEnZb"><font color="#888888"><div></div><div>-Mostyn.</div></font></span><div><div class="gmail-h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Kim<br>
<div class="gmail-m_-3986617143637162064m_-1463513666147486252m_2568606105615582320m_89769964241318080HOEnZb"><div class="gmail-m_-3986617143637162064m_-1463513666147486252m_2568606105615582320m_89769964241318080h5"><br>
On Wed, Apr 11, 2018 at 7:08 PM, via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
> If you want to share ASTs (an ephemeral structure) clang would need to do<br>
> the distributing. If you want to share IR of instantiated templates, you<br>
> can do a shared database where clang is much less involved in managing the<br>
> distribution. Say the database key can be maybe a hash of the token stream<br>
> of the template definition would work? plus the template parameters. Then<br>
> you can pull precompiled IR out of the database (if you want to do<br>
> optimizations) or make a reference to it (if you're doing LTO).<br>
><br>
> --paulr<br>
><br>
><br>
><br>
> From: cfe-dev [mailto:<a href="mailto:cfe-dev-bounces@lists.llvm.org" target="_blank">cfe-dev-bounces@lists.<wbr>llvm.org</a>] On Behalf Of David<br>
> Blaikie via cfe-dev<br>
> Sent: Wednesday, April 11, 2018 11:09 AM<br>
> To: David Chisnall<br>
> Cc: Bruce Dawson; Daniel Cheng; <a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>;<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>; Daniel Bratell; Jens Widell<br>
> Subject: Re: [cfe-dev] JumboSupport: making unity builds easier in Clang<br>
><br>
><br>
><br>
> This would have issues with distributed builds, though, right? Unless clang<br>
> then took on the burden of doing the distribution too, which might be a bit<br>
> much.<br>
><br>
> On Wed, Apr 11, 2018 at 12:43 AM David Chisnall via cfe-dev<br>
> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> On 10 Apr 2018, at 21:28, Daniel Bratell via cfe-dev<br>
> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> I've heard (hearsay, I admit) from profiling that it seems the single<br>
>> largest time consumer in clang is template instantiation, something I assume<br>
>> can't easily be prepared in advance.<br>
>><br>
>> One example is chromium's chrome/browser/browser target which is 732 files<br>
>> that normally need 6220 CPU seconds to compile, average 8,5 seconds per<br>
>> file. All combined together gives a single translation unit that takes 400<br>
>> seconds to compile, a mere 0.54 seconds on average per file. That indicates<br>
>> that about 8 seconds per compiled file is related to the processing of<br>
>> headers.<br>
><br>
> It sounds as if there are two things here:<br>
><br>
> 1. The time taken to parse the headers<br>
> 2. The time taken to repeatedly instantiate templates that the linker will<br>
> then discard<br>
><br>
> Assuming a command line where all of the relevant source files are provided<br>
> to the compiler invocation:<br>
><br>
> Solving the first one is relatively easy if the files have a common prefix<br>
> (which can be determined by simple string comparison). Find the common<br>
> prefix in the source files, build the clang AST, and then do a clone for<br>
> each compilation unit. Hopefully, the clone is a lot cheaper than<br>
> re-parsing (and can ideally share source locations).<br>
><br>
> The second is slightly more difficult, because it relies on sharing parts of<br>
> the AST across notional compilation units.<br>
><br>
> To make this work well with incremental builds, ideally you’d spit out all<br>
> of the common template instantiations into a separate IR file, which could<br>
> then be used with ThinLTO.<br>
><br>
> Personally, I would prefer to have an interface where a build system can<br>
> invoke clang with all of the files that need building and the degree of<br>
> parallelism to use and let it share as much state as it wants across builds.<br>
> In an ideal world, clang would record which templates have been instantiated<br>
> in a prior build (or a previous build step in the current build) and avoid<br>
> any IRGen for them, at the very least.<br>
><br>
> Old C++ compilers, predating linker support for COMDATs, emitted templates<br>
> lazily, simply emitting references to them, then parsing the linker errors<br>
> and generating missing implementations until the linker errors went away.<br>
> Modern C++ compilers generate many instantiations of the same templates and<br>
> then discard most of them. It would be nice to find an intermediate point,<br>
> which worked well with ThinLTO, where templates could be emitted once and be<br>
> available for inlining everywhere.<br>
><br>
> David<br>
><br>
> ______________________________<wbr>_________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
><br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div></div></div><br><br clear="all"><span class="gmail-"><div><br></div>-- <br><div class="gmail-m_-3986617143637162064m_-1463513666147486252m_2568606105615582320m_89769964241318080gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Mostyn Bramley-Moore<div><div>Vewd Software</div><div><a href="mailto:mostynb@opera.com" target="_blank">mostynb@vewd.com</a></div></div></div></div></div></div></div></div></div></div>
</span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Mostyn Bramley-Moore<div><div>Vewd Software</div><div><a href="mailto:mostynb@opera.com" target="_blank">mostynb@vewd.com</a></div></div></div></div></div></div></div></div></div></div>
</div></div>