[PATCH] D22356: [ThinLTO] Perform conservative weak/linkonce resolution in distributed backend case

Xinliang David Li via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 18 21:24:39 PDT 2016


>
> > We use --start-lib/--end-lib internally instead of regular objects. So
> it is not a matter of justification, it is a matter of keeping that working.
>
>
> I don't believe this is relevant: the fact that the first link is taking
> libraries as an input does not make it a compelling case to use them for
> the second link. Static libraries or start-lib/end-lib are a specific
> semantic model, and I believe it is just wrong to pass them to the final
> link.
>
> The reason is that the first link is performing linker resolution: this
> decision process carry some specific semantic with archives. After this
> resolution and the ThinLTO process, there is no reason that makes sense to
> me right now to repeat this process.
>
> It is possible that it is because I have a different mental model of
> static archives right now. AFAIK, the semantic difference between plain
> objects and archive is that an object defined in an archive is loaded and
> selected by the linker only if one the symbol it defines is referenced.
>

Agree.


>
> Keeping the linker semantic with ThinLTO means that the objects and
> symbols selected during the first link should be the "source of truth":
> i.e. we don't want a different linker resolution during the second link.
> Every objects that was selected for the first link should be included in
> the second link (hence it is wrong to use --start-lib/--end-lib).
>
>

However, I don't see it being wrong to allow second link to do a final
linker resolution. The fact is that there is one single source of truth as
you said -- a program can be linked in different set of object files with
different optimization levels (e.g, O0 and O2 difference due to inlining
differences).

Of course to enable link resolution in second link,  some of the first
link's decision needs to be undone --  Teresa's patch is essentially doing
that.



> Also, the distributed build system probably needs to handle the case where
> an object in the archive was not selected to be part of the link at all,
> won't be processed by ThinLTO, and there won't be any object to pass to the
> final link. I'm not sure how you're handling this with gold right now
> though.
>

No native object file will be generated for such object in this case, so it
has no use for the final link?

David




> https://reviews.llvm.org/D22356
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160718/d0a3bd03/attachment.html>


More information about the llvm-commits mailing list