[LLVMdev] RFC: ThinLTO Impementation Plan

[David Blaikie]

On Fri, May 15, 2015 at 8:26 AM, Xinliang David Li <xinliangli at gmail.com>
wrote:

> There is no need for emitting the full symtab. I checked the overhead with
> a huge internal C++ source. The overhead of symtab + str table compared
> with byte code with debug is about 3%.
>
> More importantly, it is also possible to use the symtab also for
> index/summary purpose, which makes the space usage completely 'unwasted'.
> That gets into the details which will follow when patches are in.
>

That direction ends up more heavily leaning on this model, though. Keeping
all the LLVM stuff (including summary info) in the IR means that on
platforms with bitcode-aware tools (like, by the sounds of it, OSX with ld
being bitcode aware, etc) we can support a nice bitcode-only solution.
Wrapping that in native object files for backwards compatibility for a few
tools seems OK, but the more features we build on top of that foundation
the harder it is to get out of that business when/where the backwards
compatibility isn't needed.

Also, leaving the wrapping as a separate backwards compatibility thing
would, I imagine, ease testing by making more parts testable without the
added complexity of the wrapping.

It'd be useful to see the sorts of build system scenarios that use these
native object tools so we can look at what we can/can't reasonably support.
(I assume tools aren't generally expecting a symtab where the symbols
aren't actually in the .text section - I don't know what/if any/how some of
these tools might do the wrong thing when presented with such info - but
this is all outside of my depth/area, so don't worry about explaining it to
me, but it seems other people care about what we're supporting here, at
least)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150515/330a8e5a/attachment.html>