similar to: How to get the loop hotness data in a suite ?

Dear Duncan, I am generating branch-weights annotated IR files as described in the documentation of LLVM, using profiling with instrumentation. http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation e.g. llvm-profdata merge -output=$(BENCH).profdata default.profraw > clang -S -emit-llvm -O3 -fprofile-instr-use=$(BENCH).profdata -o > bench.prof.ll bench.c The issue is

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

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

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

Hi everyone, As part of my work for Mozilla's Low Level Tools team I've implemented PGO in the Rust compiler. The feature is available since Rust 1.37 [1]. However, so far we have not seen any actual performance gains from enabling PGO for Rust code. Performance even seems to drop 1-3% with PGO enabled. I wonder why that is and I'm hoping that someone here might have experience

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

Dear Duncan, Thank you a lot for your feedback. I have a problem though. The branch weights counters overflow in some files and thus I get incorrect numbers. Is there any way to find a workaround for that? Is is supposed to be a known bug or is it something that needs configuration on my part? Again, thank you a lot for your reply. Best Regards, Georgios Zacharopoulos 2016-02-03 18:23

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

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:

On Thu, Sep 12, 2019 at 8:18 AM Teresa Johnson <tejohnson at google.com> wrote: > I just have a couple suggestions off the top of my head: > - have you tried using the new pass manager > (-fexperimental-new-pass-manager)? That has access to additional analysis > info during inlining and is able to make more precise PGO based inline > decisions. > (although note the above

Hey, I am trying to use the BlockFrequencyInfoWrapperPass to obtain hotness information in my LLVM pass. Attached is a minimal example of code which creates a SIGSEGV. The pass calls AU.addRequired<BlockFrequencyInfoWrapperPass>(); in getAnalysisUsage(..). The problem exists with changed and unchanged IR. The binary is instrumented like this: clang input.bc -fprofile-generate -o

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

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

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

Interesting. By ld do you mean GNU ld? I know GNU ld does "work" with LLVM's gold plugin, but it's an untested combination and not recommended. I wouldn't be surprised if there were some issues around it not passing necessary info to the gold plugin. Teresa On Mon, Sep 16, 2019 at 8:41 AM Michael Woerister <mwoerister at mozilla.com> wrote: > So one interesting

Can you clarify if performance difference is caused by using different linkers at instrumentation build? If that is the case, try dump the sections of the resulting binary and compare __llvm_prf_** sections. Also check the arguments passed to the linker. It should have -u__llvm_profile_runtime to force the profile runtime to be linked in. David On Mon, Sep 16, 2019 at 8:42 AM Michael

On Sun, Apr 5, 2020 at 6:34 PM Stefanos Baziotis < stefanos.baziotis at gmail.com> wrote: > Hi Craig, > > > Adding a nuw to the add -8 is incorrect. > Yeah, I didn't mean to say it was correct. It was just an observation that > with nuw the optimization was happened and I asked if someone thought it > was somehow connected. > > > From the perspective of the

Interestingly, a C version of the same test program [1] compiled with Clang 8 does not have any problems with GNU ld: The `__llvm_prf_data` section is the same size for all three linkers. It must be something specific to the Rust compiler that's going wrong here. [1] https://github.com/michaelwoerister/rust-pgo-test-programs/tree/master/cpp_branch_weights On Tue, Sep 17, 2019 at 3:26 PM

Hi all, I'm now working on llvm-cov for a new target and have a problem here. Because of some reasons, users do not stub in the main function and after running elf file, they cannot get a default profraw. Now they want to construct a default profraw manually but don't know how data is laid out in `default profraw` file. We found a struct ProfDataIOVec in InstrProfilingWriter.c in