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
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>
Kevin, both those files give me a 500 error, are you sure they're public? On 10 January 2014 22:23, Kevin Modzelewski <kmod at dropbox.com> wrote:> 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 >> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140111/77350afb/attachment.html>