[llvm-dev] RFC: Reducing Instr PGO size overhead

[Nicolas, Laurent via llvm-dev]

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>