<div dir="ltr"><div dir="ltr">On Tue, Apr 13, 2021 at 3:02 PM Mehdi AMINI via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">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"><div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>I actually just watched the presentation, but it is a bit too high level for me to really understand what is this new "format" in practice.</div><div>As far as I remember ThinLTO bitcode should be a super-set of information compared to FullLTO. It isn't clear to me what prevents a linker implementation to take the ThinLTO bitcode and perform FullLTO on these, this was designed to allow this originally.</div><div><br></div><div>The optimization pipelines are set up differently, but that does not really affect the format I believe. A good FullLTO link implementation based on the ThinLTO bitcode would likely involve running a heavier pipeline during LTO, this is something I tried to do at the time to align the pipeline and ensure there is only one, however it was making the LTO link slower and we considered it wasn't a good tradeoff.</div></div></div></blockquote><div><br></div><div>This is something I'm interested in separately from the original topic. A while back during one of our discussions, Chandler suggested that it may be worth looking into using ThinLTO pipeline for FullLTO since FullLTO hasn't really been getting much attention in the last few years and could benefit from the work done on the ThinLTO pipeline. Aside from slower links, have you seen any improvements in terms of runtime performance?</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"><div dir="ltr"><div dir="ltr"><div>We could also run part of the pipeline on individual modules (in parallel) before linking them together during FullLTO, which would address the performance question. It wouldn't however help when the same modules are linked into different binaries, like it is the case for LLVM test binaries which are linking over and over the same set of libraries. For this setup (which may not be common though) it is better to do as much work as possible in the first compilation phase and as little as possible during the link phase.</div><div><br></div><div>> the rest is spent on building unit tests and tools that are only used by lit tests. For the latter, we don't care about the performance, so it'd be nice to avoid doing regular LTO to speed up the build.</div><div><br></div><div>For such a case, the "ideal" setup would be to link these in a ThinLTO mode where we disable cross-module importing and just optimize/codegen in parallel. We could guarantee this way that each file is codegened once and cached and every test binary would have a cache hit on the files. This makes it "almost zero" cost over non-LTO I think.</div><div><br></div><div>Best,</div><div><br></div><div>-- </div><div>Mehdi</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 13, 2021 at 2:46 PM via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.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 lang="EN-US" style="overflow-wrap: break-word;">
<div>
<p class="MsoNormal">Hi Petr,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">This does sound like a good use case for our pipeline. We’ve seen good runtime performance overall, as we stated in the talk. I’ve been working on upstreaming our patches off and on for a couple months now. Our pipeline needs to be ported
 to the NPM, but once that work is done, the patch is ready for review. I should be able to finish that work within the next month or two and would love to get some feedback on our approach.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
<p class="MsoNormal">Matthew<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-style:none none none solid;border-left-width:1.5pt;border-left-color:blue;padding:0in 0in 0in 4pt">
<div>
<div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Steven Wu <<a href="mailto:stevenwu@apple.com" target="_blank">stevenwu@apple.com</a>> <br>
<b>Sent:</b> Tuesday, April 13, 2021 2:39 PM<br>
<b>To:</b> David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>><br>
<b>Cc:</b> Petr Hosek <<a href="mailto:phosek@google.com" target="_blank">phosek@google.com</a>>; Voss, Matthew <<a href="mailto:Matthew.Voss@sony.com" target="_blank">Matthew.Voss@sony.com</a>>; Teresa Johnson <<a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a>>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> Re: [llvm-dev] Supporting Regular and Thin LTO with a Single LTO Bitcode Format<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">This is a really good thread to read: <a href="https://lists.llvm.org/pipermail/llvm-dev/2018-April/122469.html" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2018-April/122469.html</a><u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">There is no fundamental technical reasons why this cannot happen but it requires lots of work to fine tuning the pipeline (yes, fullLTO and thinLTO uses different pipeline) so that it reaches a good balance of performance/build overhead
 for general users.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Steven<u></u><u></u></p>
<div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">On Apr 13, 2021, at 2:23 PM, David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">+Matthew and Teresa for any context they might have<br>
<br>
High level sounds like a reasonable thing to me, for what it's worth.<br>
<br>
On Tue, Apr 13, 2021 at 2:19 PM Petr Hosek via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal"><br>
We're using regular LTO for our Clang toolchain build because we don't mind spending more resources to squeeze out as much performance as possible. However, when looking into our build performance, I've noticed that we only spent about 1/3 of the total build
 time in building distribution components, the rest is spent on building unit tests and tools that are only used by lit tests. For the latter, we don't care about the performance, so it'd be nice to avoid doing regular LTO to speed up the build.<br>
<br>
The idea I had would be to use a single LTO bitcode format for all translation units, and then decide only at link time whether to use regular LTO for distribution components or ThinLTO for everything else.<br>
<br>
After doing some research, I found the "Supporting Regular and Thin LTO with a Single LTO Bitcode Format" talk presented by Matthew Voss at LLVM Developers’ Meeting 2019 which does exactly what I described, but it seems like this was only implemented downstream.<br>
<br>
Has there been any progress on upstreaming the implementation? Is there any way to do what I described using the in-tree LTO implementation?<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</blockquote>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>

_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>