[LLVMdev] RFC: ThinLTO Symbol Linkage and Renaming

[Duncan P. N. Exon Smith]

> On 2015-Jul-21, at 15:35, Xinliang David Li <xinliangli at gmail.com> wrote:
> 
> 
> 
> This scares me a little for linkonce -- there's a minor change to
> semantics if the importing module would have linked against a
> *different* definition of the same symbol -- but I'm not really
> sure it matters much.
> 
> 
> 
> This should not be an issue in practice as it exists non thinLTO compilations too. For instance changing the optimization level of one module can lead to different inline decisions and different copy of the comdat function to be picked up in the end.
> 

Good point.

>  
> >
> 
> I wonder whether a prefix would be better?
> 
> All the promotion/renaming scares me.  I feel like there may be
> dragons here we're not aware of.
> 
> 
> The promotion scheme is similar to LIPO which has been exercised on large number of huge C++ apps --  I think it is robust.

Sure, but other languages, platforms and conventions may yield
other problems.  Anyway, it's just a theoretical concern, I don't
have anything concrete!

>  
> The only concrete concern I have (once you switch to hidden
> visibility) is the interaction with non-LTO'd objects being linked
> into the same executable, but I wonder if I'm missing something
> else, too...
> 
> 
> There is an limitation (also with LIPO, LTO) that you can not compile one module say 'a.c' in thinLTO mode with the rest of the modules, and later recompile 'a.c' into 'a.o' without thinLTO and tries to mix and match with the rest of the real object files built with thinLTO unless 'a.c' is not imported by any other modules or it does not have any statics to be promoted.

Interesting.  I don't think LTO has this limitation.  But I also
don't think this is too important; if someone turns off thin-LTO for
a particular object file, the build system should detect that the
object changed and regenerate all the things that depend on it, so
there's no correctness problem here; and it seems like a rare thing
to toggle, so I can't see this really causing a concern for compile
time.