similar to: InstrProf backward compatibility

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

We are trying to get PGO working for our embedded out-of-tree target, but the utility 'llvm-profdata' does not like the data we are giving it. Because this is not a hosted environment, we have to off-chip the profiling data ourselves, and although the data looks okay, 'llvm-profdata' reports the following error: llvm-profdata show -all-functions -counts -detailed-summary -text

Can we improve the error message here? We should be able to check zlib::isAvailable and give an error like "profile uses zlib compression but the profile reader was built without zlib support" or so in this case. Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> writes: > The __llvm_prf_names section is compressed but your llvm-profdata tool is > probably not built

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

set LLVM_ENABLE_ZLIB=ON with cmake invocation. zlib should be installed and zlib.h header file needs to be in the header search path. Is your llvm-profdata tool built together with clang? David On Tue, Jul 18, 2017 at 1:04 PM, Martin J. O'Riordan via llvm-dev < llvm-dev at lists.llvm.org> wrote: > How can I build the profile reader with ZLIB support enabled? I configure > and

Hi David, When I use CMake to configure, ‘zlib’ and its header are detected - I build on CentOS 6.5 or CentOS 7. Since I run CMake from the command-line, I tried added ‘-DLLVM_ENABLE_ZLIB=0’ and ‘-DLLVM_ENABLE_ZLIB=1’ (using ‘-DLLVM_ENABLE_ZLIB=ON’ does not seem to work). Both ‘clang’ and ‘llvm-profdata’ (and all other tools and utilities) are configured and built together, in any event,

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

Duncan, Justin, I'm about to submit a series of patches that add writing capabilities for sample profiles in both text and binary formats. Soon, I'll add a third format (to make it interoperable with GCC). I would like to add some profile maintenance utilities as well: merging, dumping and converting. It seems like the best place would be tools/llvm-profdata. But that means that I need

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

On Fri, Jan 15, 2016 at 11:41 AM, Xinliang David Li <davidxl at google.com> wrote: > Tagging profile data with such information is generally useful. My > thoughts are > > 1) such information is probably not needed to be stored in raw format > profile data -- so no runtime changes are needed -- only llvm-profdata > and indexed format need to be enhanced to support this.

Hi all, I'd liked to get your thoughts on possibly adding a generic key-value store to the profile data formats for 'metadata'. Some potential uses cases: *I. Profile Features* The most basic use could be as a central repository for internal bits of housekeeping information about the profile data. For example, to differentiate between FE and IR instrumentation:

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

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

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,

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

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

Thanks for testing out LLVM PGO and evaluated the performance. We are currently still more focused on infrastructure improvement which is the foundation for performance improvement. We are making great progress in this direction, but there are still some key missing pieces such as profile data in inliner etc. We are working on that. Once those are done, more focus will be on making more passes

Yes, that was it! Now that I took a closer look, the guide also states that I should use the stage2 build. Silly me. Thanks! On Tue, 3 Sep 2019 at 19:31, David Blaikie <dblaikie at gmail.com> wrote: > I /guess/ you actually want /path/to/release_build/llvm-profdata because > the profiles are generated from binaries compiled with the release build, > so it's the release build

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