search for: covmapping

Hi David, Vedant, It looks like we might have UB somewhere connected with reading coverage mapping serialized in v2 format (with compressed function names). I committed my patch, r266436, using the current format for .covmapping file, and then buildbots complained about it: * http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/11935/steps/check-llvm%20ubsan/logs/stdio * http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/11460/steps/check-llvm%20ubsan/logs/stdio I tried to reprodu...

> > 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.

...roved. 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 strings can be very high (~5x). The covmapping data can also be made non-allocatable. thanks, David On Tue, Sep 29, 2015 at 9:52 AM, Xinliang David Li <davidxl at google.com> wrote: > Sorry for the late update. I finally found time to implement a solution > (Solution-3) that has the best size savings (for both PGO and coverage &g...

...l >> 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 strings can be very high (~5x). The covmapping data >> can also be made non-allocatable. >> >> thanks, >> >> David >> >> On Tue, Sep 29, 2015 at 9:52 AM, Xinliang David Li <davidxl at google.com> >> wrote: >> > Sorry for the late update. I finally found time to implement a solution...

...ero 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 strings can be very high (~5x). The covmapping data >>>> can also be made non-allocatable. >>>> >>>> thanks, >>>> >>>> David >>>> >>>> On Tue, Sep 29, 2015 at 9:52 AM, Xinliang David Li <davidxl at google.com> >>>> wrote: >>>> >...

>> >> >> >> 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. >> >> >> > >> >>

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 >> >

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 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