similar to: [LLVMdev] RFC - A tool to convert profiles from external profilers

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

The frontend-driven instrumentation based profiling used for clang's -fprofile-instr-generate and -fprofile-instr-use currently has logic for handling its data format spread about a few different places: 1. Reading files is done in clang when -fprofile-instr-use is specified. The logic is in CodeGen/CodeGenPGO.cpp. 2. Reading files is done by the (very preliminary) llvm-profdata tool,

On Sun, Oct 26, 2014 at 3:47 PM, Jeremy Lakeman <Jeremy.Lakeman at gmail.com> wrote: > This sounds like a problem best solved by tracking source code movement via > your source control system. > If you know the commit of the code that produced the sample, you should be > able to use source control history / diffs to translate absolute line > numbers to the location where the

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

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 Oct 24 2014 at 6:21:14 PM David Blaikie <dblaikie at gmail.com> wrote: > On Fri, Oct 24, 2014 at 3:16 PM, Diego Novillo <dnovillo at google.com> > wrote: > >> >> >> On Fri Oct 24 2014 at 6:11:21 PM David Blaikie <dblaikie at gmail.com> >> wrote: >> >>> On Fri, Oct 24, 2014 at 2:48 PM, Diego Novillo <dnovillo at

On Fri Oct 24 2014 at 6:11:21 PM David Blaikie <dblaikie at gmail.com> wrote: > On Fri, Oct 24, 2014 at 2:48 PM, Diego Novillo <dnovillo at google.com> > wrote: > >> I'm not sure if this was intended, but it's going to be a problem for >> sample profiles. >> >> When we compile with -gmlt, the profiler expects to find the line number >>

On Sun, Oct 26, 2014 at 4:59 PM, Eric Christopher <echristo at gmail.com> wrote: > On Fri, Oct 24, 2014 at 3:27 PM, Diego Novillo <dnovillo at google.com> > wrote: > > > > > > On Fri Oct 24 2014 at 6:21:14 PM David Blaikie <dblaikie at gmail.com> > wrote: > >> > >> On Fri, Oct 24, 2014 at 3:16 PM, Diego Novillo <dnovillo at

I'm not sure if this was intended, but it's going to be a problem for sample profiles. When we compile with -gmlt, the profiler expects to find the line number for all the function headers so that it can compute relative line locations for the profile. The tool that reads the ELF binary is not finding them, so it writes out absolute line numbers, which are impossible to match during the

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

On Fri, Oct 24, 2014 at 4:06 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > Diego, > > I think sampleFDO needs to be designed in a way which can protect itself > from future breakage like this. The roots in the unnecessary dependency of > sample FDO on gmlt setting. It is totally reasonable to tune debug binary > size by changes like this. > > The right way

I'm writing a C++ program that uses LLVM, and trying to build it with autotools. Thanks to Diego Novillo, there is an M4 macro that detects llvm-config: https://github.com/google/autofdo/blob/master/m4/ax_llvm.m4 How do I use it? Given that I've written a basic configure.ac that can compile a basic C++ program, how do I modify it to make use of the macro? And should the macro be copied

For -Rpass, and other related uses, I am looking at enabling column info by default. David pointed me at PR 14106, which seems to be the original motivation for introducing -gcolumn-info. However, I am finding no differences when using it on this test. I've tried building with/without -gcolumn-info and found almost no difference in compile time (+0.4%): $ /usr/bin/time clang -w -fno-builtin

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

Jack's correct about moving this to autoconf at gnu.org. However, you can start by cutting and pasting the configure.ac bits from the same github repo I pointed you to earlier today. The actual commit that brought those changes may be easier to use as a template. https://github.com/google/autofdo/pull/30/commits/0029f4be825f851b9d99bcd19dcb34fd59f1775e On Wed, Mar 23, 2016 at 4:35 PM,

I have started looking at the state of PGO (Profile Guided Optimization) in LLVM.**I want to discuss my high-level plan and make sure I'm not missing anything interesting out. I appreciate any feedback on this, pointers to existing work, patches and anything related to PGO in LLVM. I will be keeping changes to this plan in this web document

Hi All, Our team at Facebook is building a new context-sensitive Sample PGO as an alternative to the existing AutoFDO. We’d like to share our motivation, propose a new design, and reveal preliminary results on benchmarks. We will refer to the proposed design as CSSPGO in this RFC. The new CSSPGO leverages simultaneous LBR and stack sampling to construct a full context-sensitive profile. It

See my answers inline. From: Xinliang David Li <davidxl at google.com> Date: Friday, August 7, 2020 at 7:57 PM To: Wenlei He <wenlei at fb.com> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, Wei Mi <wmi at google.com>, Hongtao Yu <hoy at fb.com> Subject: Re: [RFC] Context-sensitive Sample PGO with Pseudo-Instrumentation On Fri, Aug 7,

On Sun, Oct 26, 2014 at 7:23 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > The fundamental questions we need to answer are the following: > FWIW, there was a longer discussion on the lists when the actual option was added. I'll try to relay my memory of that discussion, but you might need to track it down or involve some of the other people who participated in it.

On 2013-06-12 17:23 , Diego Novillo wrote: > > I have started looking at the state of PGO (Profile Guided > Optimization) in LLVM.**I want to discuss my high-level plan and make > sure I'm not missing anything interesting out. I appreciate any > feedback on this, pointers to existing work, patches and anything > related to PGO in LLVM. Good grief. A whole lot of fail