Nicolas, Laurent via llvm-dev
2015-Sep-09 00:43 UTC
[llvm-dev] RFC: Reducing Instr PGO size overhead
Thank you for doing this. The size issue is actually a big concern for me. So this is step in the right direction. Two other points to consider, that would help us: 1) When using -fcoverage-mapping, some of the information is emitted in the text section. This is creating linking issues with very large files. It does not seem any of this information should necessarily be in the text section. 2) Could the information emitted for -fcoverage-mapping be placed into their own section(s)? The objective is to be able to strip the sections for embedded systems. But we could still use the original (unstripped) binary to run llvm-cov. Thank you Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150909/529a1af2/attachment.html>
Sean Silva via llvm-dev
2015-Sep-09 04:14 UTC
[llvm-dev] RFC: Reducing Instr PGO size overhead
On Tue, Sep 8, 2015 at 5:43 PM, Nicolas, Laurent via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Thank you for doing this. > > > > The size issue is actually a big concern for me. So this is step in the > right direction. >Out of curiosity, could you explain your use case a bit more? In particular could you elaborate on the size issues that you are encountering? (from past experience, I have a pretty clear idea of google's size issues, so I didn't explicitly ask for it in this thread). -- Sean Silva> > > Two other points to consider, that would help us: > > > > 1) When using -fcoverage-mapping, some of the information is emitted > in the text section. This is creating linking issues with very large > files. It does not seem any of this information should necessarily be in > the text section. > > > > 2) Could the information emitted for -fcoverage-mapping be placed > into their own section(s)? The objective is to be able to strip the > sections for embedded systems. But we could still use the original > (unstripped) binary to run llvm-cov. > > > > Thank you > > Laurent > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150908/5960a232/attachment.html>
Nicolas, Laurent via llvm-dev
2015-Sep-21 17:15 UTC
[llvm-dev] RFC: Reducing Instr PGO size overhead
Hi Sean I alluded to 2 of the issues in my previous post. 1) We have a couple of very large libraries. The link fails if I add -fcoverage-mapping. I would think that the mapping information should not matter for the runtime, so I’d expect the link to succeed, even if we have a lot of metadata that will be used by llvm-cov. 2) We’re shipping the code as an appliance, where the distribution is stored in flash memory. Legacy platforms have a small memory size, so being able to strip the metadata would be very useful. We can keep the object files with the metadata on our data servers, so that they can used when running llvm-cov, but the runtime should be able to use the stripped versions, to save space (and maybe load a bit faster). Thank you Laurent From: Sean Silva [mailto:chisophugis at gmail.com] Sent: Tuesday, September 08, 2015 9:14 PM To: Nicolas, Laurent <Laurent.Nicolas at netapp.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] RFC: Reducing Instr PGO size overhead On Tue, Sep 8, 2015 at 5:43 PM, Nicolas, Laurent via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Thank you for doing this. The size issue is actually a big concern for me. So this is step in the right direction. Out of curiosity, could you explain your use case a bit more? In particular could you elaborate on the size issues that you are encountering? (from past experience, I have a pretty clear idea of google's size issues, so I didn't explicitly ask for it in this thread). -- Sean Silva Two other points to consider, that would help us: 1) When using -fcoverage-mapping, some of the information is emitted in the text section. This is creating linking issues with very large files. It does not seem any of this information should necessarily be in the text section. 2) Could the information emitted for -fcoverage-mapping be placed into their own section(s)? The objective is to be able to strip the sections for embedded systems. But we could still use the original (unstripped) binary to run llvm-cov. Thank you Laurent _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150921/f7120d8e/attachment-0001.html>