similar to: My experience using -DLLVM_BUILD_INSTRUMENTED_COVERAGE to generate coverage

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.

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,

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

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

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

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

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

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

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 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, I followed two posts as my guideline http://lists.llvm.org/pipermail/llvm-dev/2017-September/117339.html and http://lists.llvm.org/pipermail/llvm-dev/2017-September/117156.html I am using clang 4.0.1 and compiler-rt 4.0 release 1. I made changes in the LCF to mimic Linux Platform (for linker magic) In data section i have added: __start___llvm_prf_cnts = .;

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

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

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

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,

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 All, I want to provide a solution that presents code coverage reports that include the aggregated code-counts across many binaries. Our test engineers currently do this using gcov-mode by merged .gcda data files. We can do a similar merge of the .profraw files, so that the many binaries are represented in one .profdata file; However, llvm-cov will only generate reports based on one binary 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

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

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