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

Xinliang David Li via llvm-dev llvm-dev at lists.llvm.org
Mon Sep 21 11:06:05 PDT 2015


thanks for sharing your use case.

I haven't able to update on this topic due to other commitments. Will get
back to it soon.

David


On Mon, Sep 21, 2015 at 10:15 AM, Nicolas, Laurent via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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> 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
>
>
>
> _______________________________________________
> 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/20150921/0b757db3/attachment.html>


More information about the llvm-dev mailing list