[LLVMdev] RFC: ThinLTO Impementation Plan
Xinliang David Li
xinliangli at gmail.com
Fri May 15 10:49:40 PDT 2015
On Fri, May 15, 2015 at 10:07 AM, Dave Bozier <seifsta 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%.
>
> It's still sizable and could be noticeable if thinLTO can deliver compile
> times that closer to what resembles builds without LTO as your results
> suggest.
>
If the cost is part of the index/summary, then it is avoidable.
>
> > 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.
>
>
> There is symbol information in both the native object symbol table and the
> bitcode file? isn't that waste? I understand the reasons for using the
> native object wrapper (compatibility with other tools) and happy with that.
> But I'd also like to see the option for function index/summary data to be
> produced without the wrapper, so that bitcode aware tools do not need to
> use this wrapped format.
>
I agree.
> If you mix the native object wrapper symbol information with the
> function/index summary data then that would end up being impossible.
>
It is possible. The summary data is still in its own proper (its own
section). Under the bitcode only option, the symtab will be replaced with
bitcode form of the index, while the summary remains the same.
>
> Also won't having the native object data with the function index/summary
> have a cost on testing for all of the supported native object formats?
>
yes.
thanks,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150515/f2a69004/attachment.html>
More information about the llvm-dev
mailing list