[LLVMdev] RFC: ThinLTO Symbol Linkage and Renaming

[Xinliang David Li]

On Mon, Jul 27, 2015 at 1:06 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

>
> > 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.


Its main usage I can see is for bug triaging (using object mix&match) --
there are other ways to do that. For instance 1) add option to force static
promotion for O2 or selectively disabling importing etc. So right, it is
only a concern on paper.

thanks,

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150727/0beefdd5/attachment.html>