similar to: [LLVMdev] Adding sample profile support to llvm-profdata?

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

On Fri, May 22, 2015 at 11:16 AM, Dario Domizioli <dario.domizioli at gmail.com> wrote: > Hi all, > > I am a bit confused about the documentation of the format of the profile > data file. > > The Clang user guide here describes it as an ASCII text file: > http://clang.llvm.org/docs/UsersManual.html#sample-profile-format > > Whereas the posts above and the

I haven't tested it, but it looks to me like llvm-profdata merge (well, InstrProfWriter specifically) would not have deterministic output. Certainly the textual output iterates over FunctionData which is a StringMap of SmallDenseMaps, neither of which has deterministic iteration. The binary writing looks like it'd have similar issues - looping through these unordered maps & writing

Hi all, I am working on adding PGO to LDC (LLVM D Compiler). The current implementation 1) uses LLVM's InstrProf pass to generate an instrumented executable 2) links to compiler-rt/lib/profile for the runtime functionality to write a raw profile data file 3) uses llvm-profdata to merge profile data and convert from profraw to profdata format 4) uses llvm::IndexedInstrProfReader to read-in

On 2015 Jun 17, at 13:53, Diego Novillo <dnovillo at google.com> wrote: > The flags -fprofile-generate and -fprofile-use are currently ignored > for GCC compatibility. I would like to enable them and give them > similar semantics to GCC. These flags are baked pretty deeply into > our build environment, so supporting them at the driver level will > make our lives a lot

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

Hi all, I am a bit confused about the documentation of the format of the profile data file. The Clang user guide here describes it as an ASCII text file: http://clang.llvm.org/docs/UsersManual.html#sample-profile-format Whereas the posts above and the referenced link describe it as a stream of bytes containing LEB128s: http://www.llvm.org/docs/CoverageMappingFormat.html >From experimenting

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

On Thu, Jun 29, 2017 at 7:03 PM Xinliang David Li <davidxl at google.com> wrote: > On Thu, Jun 29, 2017 at 6:27 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> I haven't tested it, but it looks to me like llvm-profdata merge (well, >> InstrProfWriter specifically) would not have deterministic output. >> >> Certainly the textual output iterates

The flags -fprofile-generate and -fprofile-use are currently ignored for GCC compatibility. I would like to enable them and give them similar semantics to GCC. These flags are baked pretty deeply into our build environment, so supporting them at the driver level will make our lives a lot simpler. >From https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html:

+ 1 to Sean's suggestion of using a wrapper script to call profdata merge. David, does that work for your use case? Some inline comments --- > On Feb 28, 2016, at 10:45 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Feb 28, 2016, at 12:46 AM, Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >>

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 Feb 28, 2016, at 12:46 AM, Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Justin, looks like there is some misunderstanding in my email. I want to clarify it here first: > > 1) I am not proposing changing the default profile dumping model as used today. The online merging is totally optional; > 2) the on-line profile merging is not doing

On Thu, Jun 29, 2017 at 7:26 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Jun 29, 2017 at 7:03 PM Xinliang David Li <davidxl at google.com> > wrote: > >> On Thu, Jun 29, 2017 at 6:27 PM, David Blaikie <dblaikie at gmail.com> >> wrote: >> >>> I haven't tested it, but it looks to me like llvm-profdata merge (well,

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

Hi! I'm trying to build a fast Clang for myself to use for debug builds on Clang itself, but I've been struggling for a very long time on it. Could you please help? I've been following this guide: https://llvm.org/docs/HowToBuildWithPGO.html I've quickly learned that its outdated, because the script it talks about doesn't work with the monorepo layout at all, but in any

Justin, looks like there is some misunderstanding in my email. I want to clarify it here first: 1) I am not proposing changing the default profile dumping model as used today. The online merging is totally optional; 2) the on-line profile merging is not doing conversion from raw to index format. It does very simple raw-to-raw merging using existing runtime APIs. 3) the change to existing profile

On Fri, Mar 4, 2016 at 11:28 AM, Tilmann Scheller <tilmann at osg.samsung.com> wrote: > Hi Sedat, > > On 03/03/2016 08:09 AM, Sedat Dilek via llvm-dev wrote: >> >> It might be that a CLANG generated with LTO/PGO speeds up the build. >> Can you confirm this? > > Yes, a Clang host compiler built with LTO or PGO is generally faster than an > -O3 build. >

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

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