[LLVMdev] Bitcode parsing performance

Kevin Modzelewski kmod at dropbox.com
Fri Jan 10 14:23:23 PST 2014


Ok, I updated to trunk and reran (same results); here are the original and
stripped bitcode files:
https://www.dropbox.com/s/wydh5nzt10zpcfu/stdlib.bc
https://www.dropbox.com/s/1oxqbatspkovmv1/stdlib.stripped.bc

Thanks,
Kevin

On Fri, Jan 10, 2014 at 6:05 AM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

> On 10 January 2014 03:09, Sean Silva <chisophugis at gmail.com> wrote:
> > This Summer I was working on LTO and Rafael mentioned to me that debug
> info
> > is not lazy loaded, which was the cause for the insane resource usage I
> was
> > seeing when doing LTO with debug info. This is likely the reason that the
> > lazy loading was so ineffective for your debug build.
> >
> > Rafael, am I remembering this right/can you give more information? I
> expect
> > that this will have to get fixed before pitching LLD as a turnkey LTO
> > solution (not sure where in the priority list it is).
>
> In the case of LTO, there were two main issues.
>
> * Duplicate type debug information.
> * All metadata (including debug info) is loaded eagerly.
>
> As Eric mentioned, we can now merge type debug info from multiple
> translation units, which results in a smaller total size. Kevin, what
> llvm version are you using? Do you get a smaller combined bitcode with
> trunk?
>
> The issue of loading all of the debug info ahead of time is still
> there. We will need to fix that at some point or reduce its size
> further so that the impact is small enough.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140110/c4b220a8/attachment.html>


More information about the llvm-dev mailing list