[llvm-dev] Supporting Regular and Thin LTO with a Single LTO Bitcode Format

[Steven Wu via llvm-dev]

This is a really good thread to read: https://lists.llvm.org/pipermail/llvm-dev/2018-April/122469.html <https://lists.llvm.org/pipermail/llvm-dev/2018-April/122469.html>

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.

Steven

> On Apr 13, 2021, at 2:23 PM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> +Matthew and Teresa for any context they might have
> 
> High level sounds like a reasonable thing to me, for what it's worth.
> 
> On Tue, Apr 13, 2021 at 2:19 PM Petr Hosek via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> Has there been any progress on upstreaming the implementation? Is there any way to do what I described using the in-tree LTO implementation?
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210413/9673ecad/attachment.html>