<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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:0 0 0 .8ex;border-left:1px #ccc solid;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><div>I CC'ed Andy in my initial post, but the email bounced.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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><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><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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><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><br></div><div><br></div><div>-Mostyn.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Kim<br>
<div class="m_-1463513666147486252m_2568606105615582320m_89769964241318080HOEnZb"><div class="m_-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><br><br clear="all"><div><br></div>-- <br><div class="m_-1463513666147486252m_2568606105615582320m_89769964241318080gmail_signature" data-smartmail="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>