similar to: RFC: Reducing Instr PGO size overhead

We are now very close to push the final stage of the PGO size reduction task. Here is the updated plan going forward: 1) In this round, the format of the indexed profile data won't be unchanged. 2) there will be *no* changes in user interfaces to all profiling related tools including llvm-profdata, llvm-cov -- the change will be transparent in terms of PGO usability. 3) The implementation

On Fri, Oct 9, 2015 at 3:58 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Wed, Oct 7, 2015 at 11:12 PM, Xinliang David Li <davidxl at google.com> > wrote: >> >> There is no further response to this, so I will assume general >> direction of solution-3 is acceptable ;) > No response does not mean "LGTM". > What I meant is that

>> >> >> >> yes -- it is fixed length (8byte) blob which may include null byte in >> >> the middle. >> > >> > >> > For reference, MD5 sum is 16 bytes (128-bit): >> > https://en.wikipedia.org/wiki/MD5 >> >> yes, LLVM's MD5 hash only takes the lower 64bit. >> >> >> > >> >>

> > I think it is reasonable to simply replace the key we currently use with > MD5(key) for getting a size reduction. In practice for my use cases, I have > not observed any of the issues you mentioned under "Large size of overhead > can limit the usability of PGO greatly", but I can understand that some of > these issues could become problems in Google's use case.

There is no further response to this, so I will assume general direction of solution-3 is acceptable ;) Solution-3 can be further improved. Instead of using static symbol table (with zero size __llvm_prf_nm symbols) to store function names for profile display and coverage mapping, the function names can be stored compressed in a non-allocatable section. The compression ratio for function name

LLVM Profile instrumentation incurs very large size (memory, storage) overhead. For instance, the following is the binary size comparison of the Clang binaries built (-O2 -DNDEBUG) with different configurations: 1) 60.9M (built with Clang itself) 2) 280.4M (same as 1, but added -fprofile-instr-generate) 3) 54.9M (built with GCC 4.8) 4) 156.5M (same as 3, but added -fprofile-generate) In other

On Fri, Sep 4, 2015 at 5:21 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Fri, Sep 4, 2015 at 3:57 PM, Xinliang David Li <davidxl at google.com> > wrote: >> >> > >> > I think it is reasonable to simply replace the key we currently use with >> > MD5(key) for getting a size reduction. In practice for my use cases, I >> >

On Fri, Sep 4, 2015 at 9:11 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Fri, Sep 4, 2015 at 5:42 PM, Xinliang David Li <davidxl at google.com> > wrote: >> >> On Fri, Sep 4, 2015 at 5:21 PM, Sean Silva <chisophugis at gmail.com> wrote: >> > >> > >> > On Fri, Sep 4, 2015 at 3:57 PM, Xinliang David Li <davidxl at

On Fri, Sep 4, 2015 at 11:03 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Fri, Sep 4, 2015 at 10:11 PM, Xinliang David Li <davidxl at google.com> > wrote: >> >> On Fri, Sep 4, 2015 at 9:11 PM, Sean Silva <chisophugis at gmail.com> wrote: >> > >> > >> > On Fri, Sep 4, 2015 at 5:42 PM, Xinliang David Li <davidxl at

Hi all! It seems I came across on issue with coverage mapping (http://www.llvm.org/docs/CoverageMappingFormat.html) check on: llvm revision: r228136 clang Last Changed Rev: 228121 build: Debug+Asserts OS: ubuntu 14.04 Here is simple snippets test1.c: NOT OK ================== #include <stdio.h> static int foo() { return 42; } int main() { return 0; } ================== cp src/test1.c

Hi Justin , Thank you for the confirmation and we would like to know that ,going forward the clang has the support the gcc gcov format or use the -fprofile-instr-generate -fcoverage-mapping and get ride of gcov format . We are planing to customize the clang code coverage for embedded world ,before we start tweaking the gcov / -fprofile-instr-generate code-base ,we would like to take feedback

Umesh Kalappa <umesh.kalappa0 at gmail.com> writes: > Hi Justin , > > Thank you for the confirmation and we would like to know that ,going > forward the clang has the support the gcc gcov format or use the > -fprofile-instr-generate -fcoverage-mapping and get ride of gcov > format . Going forward, the -fprofile-instr-generate -fcoverage-mapping (which I'll refer to as

Hi! I am trying to get a combined coverage report from multiple executables. Looking at earlier discussions [1, 2], it looks like this is supposed to work. I am having some difficulty getting this to work as I would expect it to work, however. Following is a simple case to explain: ////////// shared.h #include <string> void Print1(const std::string& msg); void Print2(const

Quick update. I've gotten derailed from posting a patch for this due to focusing on higher priority PGO inlining work. No ETA. -- Sean Silva On Fri, Jun 3, 2016 at 6:06 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Thu, Jun 2, 2016 at 6:41 PM, Xinliang David Li <davidxl at google.com> > wrote: > >> >> >> On Thu, Jun 2, 2016 at 5:30

> On Jun 2, 2016, at 12:10 AM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Wed, Jun 1, 2016 at 5:46 PM, Frédéric Riss <friss at apple.com <mailto:friss at apple.com>> wrote: > >> On Jun 1, 2016, at 1:46 PM, Sean Silva <chisophugis at gmail.com <mailto:chisophugis at gmail.com>> wrote: >> >> >> >> On

On Thu, Jun 2, 2016 at 5:30 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Thu, Jun 2, 2016 at 2:51 PM, Frédéric Riss <friss at apple.com> wrote: > >> >> On Jun 2, 2016, at 12:10 AM, Sean Silva <chisophugis at gmail.com> wrote: >> >> >> >> On Wed, Jun 1, 2016 at 5:46 PM, Frédéric Riss <friss at apple.com> wrote:

> On Jun 1, 2016, at 1:46 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Tue, May 31, 2016 at 6:02 PM, Frédéric Riss <friss at apple.com <mailto:friss at apple.com>> wrote: > >> On May 24, 2016, at 5:21 PM, Sean Silva <chisophugis at gmail.com <mailto:chisophugis at gmail.com>> wrote: >> >> >> >> On

Hi Sadrul, > On Mar 8, 2018, at 7:40 PM, Sadrul Chowdhury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi! I am trying to get a combined coverage report from multiple > executables. Looking at earlier discussions [1, 2], it looks like this > is supposed to work. I am having some difficulty getting this to work > as I would expect it to work, however. Following is

It sounds to me we are likely to converge on the following: 1) Making IR/llvm based PGO the default; 2) Enhance -fcoverage-mapping such that it automatically turns on FE based instrumentation 3) if -fcoverage-mapping is used together with -fprofile-instr-generate, -fcoverage-mapping serves as a switch to turn on FE based instrumetnation All the above are transparent to users. The following are

On Wed, Oct 25, 2017 at 09:13:54AM -0700, Xinliang David Li wrote: > On Wed, Oct 25, 2017 at 12:26 AM, Roger Pau Monné via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > Hello, > > > > I've been working on implementing some basic functionality in order to > > use the llvm profiling functionality inside of a kernel (the Xen > > hypervisor).