[LLVMdev] RFC: ThinLTO Impementation Plan

[Xinliang David Li]

On Fri, May 15, 2015 at 1:14 PM, Eric Christopher <echristo at gmail.com>
wrote:

>
>>> I don't think that natively wrapped bitcode gets you as much as you
>>> think it does anyhow, unless you're duplicating a lot of information (ar,
>>> as discussed earlier, aside). I'm not too worried about the build system as
>>> far as a wrapping mechanism
>>>
>>
>> Do not under estimate the importance of build system integration. Tools
>>
>
> I'm pretty sure I'm never going to underestimate build system integration.
> :)
>
>
>> used in the build can include ar, nm, ranlib, objcopy, strip, etc. The
>> latest binutils  support plugin for ar, nm and ranlib, but not others.
>> objcopy can actually change visibility of symbols. It is conceivably easy
>> to support this with native object wrapper (i.e. propagate the visibility
>> change at IR reading time), but it is unclear wether existing plugin
>> interfaces are enough for it.
>>
>>
>
> Others have replied to this in more detail, but I'd like to understand
> more the compilation tools pipeline you're talking about
>


This is just an example I have seen from a highly curated build system.

The engineering solution to be taken depends on the final goal and target
users. If we are only targeting thinLTO for a small set of users who does
have good handle on their build systems, it might be a different decision.
ThinLTO has the goal to be a drop-in replacement for O2 (basically enabling
CMO everywhere), the requirement will be quite different. Making it harder
to use won't help that goal. This basically means we need to cut down the
dependency on plugins -- which can be controlled under an option.

here where you need this particular functionality. Also, the engineering
> tradeoffs in looking at the plugin interfaces rather than this.
>

With native object wrapper, we almost get it (the objcopy example) for
free. Symbol attributes can be changed in the final link step, so the
combined index/summary will contain it and be used in backend compilation
anyway.

thanks,

David



>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150515/9436b28b/attachment.html>