similar to: [LLVMdev] RFC: Instrumentation based profiling file libraries

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

Dario Domizioli <dario.domizioli at gmail.com> writes: > Hi Diego, > > thanks for clarifying the difference between the two formats. I have noticed > the new note in the "Sample Profile Format" section of the Clang guide > clarifying that it is different from the coverage format. > > So, my further question is... Am I right in understanding that both formats

Hi Diego, thanks for clarifying the difference between the two formats. I have noticed the new note in the "Sample Profile Format" section of the Clang guide clarifying that it is different from the coverage format. So, my further question is... Am I right in understanding that both formats can be used for PGO purposes then? I have tried the following, as in the Clang user guide: $

The PGO was my first guess but I can get a lot of information. At first, I follow the explanation at http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation but instead of llvm-profdata merge, I used llvm-profdata show *.profraw. Sadly, the information I get is the total number of function, the maximum function count and the maximum internal block count. Do you know if you

Hi, all Recently I'm trying to use LLVM PGO and autoFDO. However I have some problems in the process. LLVM source code is updated on April 9th. Operating system is SUSE x86_64 1. Problems in instrumentation based PGO: clang -O2 -fprofile-instr-generate test.c -o a.out ./a.out (then default.profraw is generated) clang -O2 -fprofile-instr-use=default.profraw test.c -o a.out

A few weeks ago, I announced the availability of a conversion tool that converts Linux Perf sample profiles to LLVM's sample profiler ( https://github.com/google/autofdo). I have now ported this tool to the LLVM tree, so it can be made available as part of LLVM. I've got a working version, but I still need to massage the code to use LLVM's own libraries (logging, flags, etc) and adapt

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

Hello all, I'm wondering as to the status of control flow profiling in llvm. From what I can gather there was an old system (using opt -insert-edge-profiling and the like) which was removed in this commit llvm.org/viewvc/llvm-project?view=revision&revision=191835 . The commit message mentions "modern PGO efforts", but I can't find anything in the source tree or

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

On Thu, Jun 2, 2016, 6:41 PM Xinliang David Li via llvm-dev < llvm-dev at lists.llvm.org> wrote: > 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

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

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

Yeah I have already see pintool but I need this to work with ARM and Intel. If I remember correctly, pintool does not work on ARM (or quite bad). My goal with the instrumentation is, once I have the information (time + call), to choose (during a second compilation) if some of my passes are applicable or not. Greetings, Johan On 17 Jul 2015, at 16:09, Kenneth Adam Miller <kennethadammiller

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

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 May 23, 2016, at 8:56 PM, Xinliang David Li <davidxl at google.com> wrote: > > On Mon, May 23, 2016 at 8:23 PM, Sean Silva <chisophugis at gmail.com> wrote: > Jake and I have been integrating IRPGO on PS4, and we've identified 3 remaining work items. > > Sean, thanks for the write up. It matches very well with what we think as well. + 1 > - Driver

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

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

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