similar to: RFC: Pass to prune redundant profiling instrumentation

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

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

> 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

On Fri, Mar 11, 2016 at 7:04 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Fri, Mar 11, 2016 at 6:00 PM, Vedant Kumar <vsk at apple.com> wrote: > >> >> > 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

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,

Hi Dean, We didn't discuss using XRay instrumentation during the BoF but it is an interesting idea (by the way, thanks for your talk about XRay internals!). XRay provides the advantage of being able to turn profiling on and off, but I'm not sure how the resulting data could be used. The code coverage feature is highly dependent on the frontend's profile counter placement. The mapping

Hello, Our goals for the code coverage BoF (10/19) were to find areas where we can improve the coverage tooling, and to learn more about how coverage is used. I'd like to thank all of the attendees for their input and for making the BoF productive. Special thanks to Mandeep Grang, who volunteered as a mic runner at the last minute. In this email I'll share my (rough) notes and outline

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 Sat, Aug 8, 2015 at 6:31 AM, Xinliang David Li <davidxl at google.com> wrote: > On Fri, Aug 7, 2015 at 10:56 PM, Sean Silva <chisophugis at gmail.com> wrote: > > Accidentally sent to uiuc server. > > > > > > On Fri, Aug 7, 2015 at 10:49 PM, Sean Silva <chisophugis at gmail.com> > wrote: > >> > >> Can you compare your results

Accidentally sent to uiuc server. On Fri, Aug 7, 2015 at 10:49 PM, Sean Silva <chisophugis at gmail.com> wrote: > Can you compare your results with another approach: simply do not > instrument the top 1% hottest functions (by function entry count)? If this > simple approach provides most of the benefits (my measurements on one > codebase I tested show that it would eliminate

On 6/18/2017 3:51 PM, Vedant Kumar wrote: >> My experience: >> >> 1. You have to specify -DLLVM_USE_LINKER=gold (or maybe lld works; I >> didn't try). If you link with binutils ld, the program will generate >> broken profile information. Apparently, the linked binary is missing >> the __llvm_prf_names section. This took me half a day to figure out.

+ 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

With llc, the size of the names section can vary widely depending on the value of -DLLVM_TARGETS_TO_BUILD. Enabling coverage shouldn't increase the name section size much. I only see one place where this happens, and it's relatively cold: http://lab.llvm.org:8080/coverage/coverage-reports/llvm/coverage/Users/buildslave/jenkins/sharedspace/clang-stage2-coverage-R at

On 6/27/2017 1:47 PM, Xinliang David Li wrote: > > > On Mon, Jun 26, 2017 at 7:24 PM, Friedman, Eli > <efriedma at codeaurora.org <mailto:efriedma at codeaurora.org>> wrote: > > On 6/19/2017 7:29 PM, Vedant Kumar wrote: >> >>>> We can reduce testing time by *not* instrumented basic tools >>>> like count, not, FileCheck etc. I

I had an old build of llc with FE instrumentation, the name section size is about 5MB. Using coverage is likely to cause the name section to be larger as there are more references to dead/unused function names. What do you see when readelf --string-dump=__llvm_prf_names llc David On Tue, Jun 27, 2017 at 2:23 PM, Xinliang David Li <davidxl at google.com> wrote: > > > On Tue,

Vedant Kumar asked me to post my design thoughts concerning branch coverage at llvm-dev since there is general interest. My team at Texas Instruments is developing an embedded ARM C/C++ compiler with LLVM. I would like to enhance LLVM's code coverage capability with branch condition coverage (for C/C++), similar to GCC/GCOV support for branch coverage. This is useful for TI, and I think

This proposal adds support for path profiling [Ball96] to LLVM. Path profiling compactly represents acyclic paths in a directed acyclic graph representation of the control flow graph of a routine. Instrumentation can be added to uniquely identify paths executed at runtime. Path profiles enable precise enumeration of the sequence of basic blocks executed in order for a particular path. Using path

On Thu, Jan 17, 2019 at 2:47 PM Xinliang David Li <davidxl at google.com> wrote: > > > On Thu, Jan 17, 2019 at 2:32 PM Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> On Thu, Jan 17, 2019 at 10:53 AM Xinliang David Li <davidxl at google.com> >> wrote: >> >>> Hi Manman, >>> >>> Ordering profiling is

On 6/19/2017 7:29 PM, Vedant Kumar wrote: > >>> We can reduce testing time by *not* instrumented basic tools like >>> count, not, FileCheck etc. I filed: llvm.org/PR33501 >>> <http://llvm.org/PR33501>. >>> >>>> 3. The generated profile information takes up a lot of space: llc >>>> generates a 90MB profraw file. >>>

Hello, We have a user that wants to get the code coverage report for his library without turning on instrumentation for the library clients or change how they are built (only the library is instrumented). It seems like the inline member functions defined in headers are not instrumented in this case because the clients are not instrumented. The library itself does not have a copy of the inline