[PATCH] D27324: IPO: Introduce ThinLTOBitcodeWriter pass.

Peter Collingbourne via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 5 16:32:07 PST 2016


pcc added a comment.

In https://reviews.llvm.org/D27324#613964, @mehdi_amini wrote:

> In https://reviews.llvm.org/D27324#613959, @pcc wrote:
>
> > > Basically we want to cache the combined module
> >
> > By which I mean the object file representing the combined module, sorry.
>
>
> I'm not totally sure about this (the time to hash the IR may be almost as long as the codegen for this module if it contains "only" the Vtables). But that's a detail that can be tuned later.


At least the LowerTypeTests pass needed for CFI can get expensive, so I'd like to be able to cache its output. But it may be possible to optimize that pass further (the pass hasn't historically shown up in profiles simply because it was being run along with the other regular LTO passes), so ok, let's think about what to do about it later.

FWIW for hashing I was thinking that we'd just read the MODULE_CODE_HASH.

> I'm more interested to understand the flow of devirtualization in particular. How do we know which type resolution impact which ThinLTO backend? 
>  I haven't all the pieces of the flow yet.

This was discussed on the original RFC thread, and the conclusion was at the end of this message:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/106628.html
Basically the information is stored in the individual summaries.


https://reviews.llvm.org/D27324





More information about the llvm-commits mailing list