similar to: [LLVMdev] RFC: Binary format for instrumentation based profiling data

On Mar 13, 2014, at 5:48 AM, Diego Novillo <dnovillo at google.com> wrote: > On Wed, Mar 12, 2014 at 9:09 PM, Justin Bogner <mail at justinbogner.com> wrote: > >> Functions are represented by strings, determined by the part of the >> frontend that both generates and uses this data. In our case, these are >> generally whatever clang thinks of as the

Chandler Carruth <chandlerc at google.com> writes: > The other assumption here is that you want the same file format written by > instrumentation and read back by the compiler. While I think that is an > unsurprising goal, I think it creates quite a few limitations that I'd like to > point out. I think it would be worthwhile to consider the alternative of > having the

On Thursday, March 13, 2014, Diego Novillo <dnovillo at google.com> wrote: > > On Mar 13, 2014 6:57 PM, "Bob Wilson" <bob.wilson at apple.com<javascript:_e(%7B%7D,'cvml','bob.wilson at apple.com');>> > wrote: > > > > > This is a proposal for the instrumentation-based approach that I talked > about at the dev meeting. I

Hi Not sure if this is a clang or llvm related question so I'm sending to both mailing lists. Anyways, I have few questions regarding size and execution time of instrumented code: We are trying to run code coverage on memory limited hardware and investigating both (generating gcov output using -coverage and the llvm's own way using -fprofile-instr-generate -fcoverage-mapping clang flags)

On Sat, Mar 22, 2014 at 1:18 AM, Justin Bogner <mail at justinbogner.com>wrote: > Chandler Carruth <chandlerc at google.com> writes: > > I think it would be worthwhile to consider the alternative of having > > the profile library write out data files in a format which is > > essentially "always" transformed by a post-processing tool before > >

There have been a lot of responses. I'll try to summarize the thread and respond to some of the questions/feedback. Summary ======= 1. We should teach GlobalDCE to strip out instrumented functions which the inliner cannot delete. 2. Sean suggests adding metadata to loads/stores of counters to convey that they do not alias normal program data. I'm not familiar with AA, but

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

George Karpenkov <ekarpenkov at apple.com> writes: > OK so with Kuba’s help I’ve found the error: with optimization, dead > stripping of produced libraries is enabled, > which removes coverage instrumentation. > > However, this has nothing to do with the move to compiler-rt, so I’m > quite skeptical on whether it has worked > beforehand. > > A trivial fix is to do:

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

> We seem to have some agreement that two formats for instrumentation > based profiling is worthwhile. These are that emitted by compiler-rt in > the instrumented program at runtime (format 1), and that which is > consumed by clang when compiling the program with PGO (format 2). > > Format 1 > -------- > > This format should be efficient to write, since the

On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Aug 24, 2017 at 3:20 PM, Justin Bogner <mail at justinbogner.com> > wrote: > >> I think the simplest fix is something like this: >> >> diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp >>

> On Aug 24, 2017, at 2:55 PM, Kostya Serebryany <kcc at google.com> wrote: > > Interesting. > This is a relatively new addition (fsanitize-coverage=pc-tables, which is now a part of -fsanitize=fuzzer). > The tests worked (did they? On Mac?) so I thought everything is ok. For tests we never compile the tested target with -O3 (and that wouldn’t be sufficient), and for

I think the simplest fix is something like this: diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp index c6f0d17f8fe..e81957ab80a 100644 --- a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp +++ b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp @@ -256,6 +256,7 @@ SanitizerCoverageModule::CreateSecStartEnd(Module

"Betul Buyukkurt" <betulb at codeaurora.org> writes: >> - We don't need to store the value profiling kind in the data at all. >> The frontend knows which invocations of the intrinsic are for each kind >> implicitly, much like it knows the difference between a counter for an >> "if" and a "for" apart implicitly. Just store one

On Fri, Mar 28, 2014 at 1:33 PM, Justin Bogner <mail at justinbogner.com>wrote: > Chandler Carruth <chandlerc at google.com> writes: > > Format 2 > > -------- > > > > This format should be efficient to read and preferably reasonably > > compact. We'll convert from format 1 to format 2 using llvm-profdata, > > and clang

On Thu, Mar 10, 2016 at 10:13 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Thu, Mar 10, 2016 at 9:42 PM, Xinliang David Li <xinliangli at gmail.com> > wrote: > >> >> >> On Thu, Mar 10, 2016 at 8:33 PM, Sean Silva via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>> On Thu, Mar 10,

+ Vedant Hi Hal, thanks. I apologize if my answers aren't as thorough as you would like; what I'm proposing is simply an extension to the existing infrastructure, so it would be enabled automatically as part of code coverage. Mapping of branch regions would be done in CoverageMappingGen and instrumented using the same profiling instrumentation mechanism under

On Thu, Mar 10, 2016 at 8:33 PM, Sean Silva via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Mar 10, 2016 at 7:21 PM, Vedant Kumar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> I'd like to add a new pass to LLVM which removes redundant profile counter >> updates. The goal is to speed up code coverage

Instrumentation based Profile Guided Optimization (PGO) is a compiler technique that leverages important program runtime information, such as precise edge counts and frequent value information, to make frequently executed code run faster. It's proven to be one of the most effective ways to improve program performance. An important design point of PGO is to decide where to place the

> On Mar 11, 2016, at 5:28 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Fri, Mar 11, 2016 at 12:47 PM, Vedant Kumar <vsk at apple.com> wrote: > There have been a lot of responses. I'll try to summarize the thread and respond > to some of the questions/feedback. > > > Summary > ======= > > 1. We should teach GlobalDCE to