[LLVMdev] RFC: ThinLTO Impementation Plan

[Duncan P. N. Exon Smith]

> On 2015-May-15, at 07:30, Teresa Johnson <tejohnson at google.com> wrote:
> 
>> Ah, here it is.  Should have read ahead.
>> 
>> How do you plan to handle references to other GlobalValues (global
>> variables, functions, and aliases)? If you're going to keep loading
>> the symbol table (which I think you need to?), then the lazy loader
>> already creates a function index.  Or do you have some other plan?
> 
> We do have to reload the declarations and other symbol table info.
> Where it differs from the lazy loader is that we don't need to keep
> parsing the module to build up the function index
> (DeferredFunctionInfo), with repeated calls to
> FindFunctionInStream/ParseModule. Once we hit the first function body
> we stop, then when materializing we simply set up the
> DeferredFunctionInfo entry from the bitcode index that was saved in
> the ThinLTO function index.
> 
>> 
>> If an imported function references functions with internal linkage,
>> will you pull in copies of those functions as well?
> 
> There are two possibilities in this case: promotion (along with
> renaming to avoid name clashing with other modules), or force import.
> As you note later on, I talk about promotion just below here. To limit
> the required static promotions I have implemented a strategy where we
> attempt to force import referenced functions that have internal
> linkage. But we still must do static promotion if the local function
> (or global) is potentially imported to another module (in the combined
> function map) and is address exposed.
> 
>> 
>> If an imported function references global variables with internal
>> linkage... actually, that doesn't seem legal.  Will you disallow
>> importing such functions?  How will you mark them?
> 
> Static promotion handles this.

[snip]

> On 2015-May-15, at 07:30, Teresa Johnson <tejohnson at google.com> wrote:
> 
>>> This can be in-memory initially,
>>> but IR support may be required in order to support streaming bitcode
>>> out and back in again after importing.
>>> 
>>> - ModuleLinker changes to do ThinLTO-specific symbol linking and
>>> static promotion when necessary. The linkage type of imported
>>> functions changes to AvailableExternallyLinkage, for example. Statics
>>> must be promoted in certain cases, and renamed in consistent ways.
>> 
>> Ah, could have read ahead again; this answers my questions about
>> referencing global variables with local linkage.
>> 
>> It also sounds pretty hairy.  Details welcome.
> 
> It has to be well thought out for sure. We had to do this for LIPO as
> well so already knew what needed to be done here. I will put together
> more details in a follow-on email.

A separate thread SGTM.  I think it's a fairly big topic.

Please include information on how you avoid name clashes globally, and
how you demote the functions back to internal or private linkage before
the end of the link.