[LLVMdev] RFC: ThinLTO Impementation Plan
Xinliang David Li
xinliangli at gmail.com
Fri May 15 10:32:01 PDT 2015
(resend a bounced message).
>
>> 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
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.
>
>
>> and I think more traditional LTO schemes with LLVM have just used
>> bitcode/IR output as an input to the LTO link step. I think what we're
>> talking about here is the best way to encode the data that thin lto
>> needs/wants in order to handle summary information etc right?
>>
>
Not entirely. We want both functionality and usability. Easy integration
with build is considered as the usability. Asking users to use wrapper
tools in order to pass plugin path is not something I consider as being
highly usable -- but I can be convinced the other way :)
David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150515/8ae60c79/attachment.html>
More information about the llvm-dev
mailing list