similar to: [RFC] Context-sensitive Sample PGO with Pseudo-Instrumentation

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,

Thanks for the thoughtful questions, David. See my answers inline. Thanks, Wenlei From: Xinliang David Li <davidxl at google.com> Date: Friday, August 7, 2020 at 1:24 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

Hi Rahman, Thanks for sharing the BB-info section proposal which is a shiny idea. I think the BB-info and pseudo probes deal with a similar problem in different spaces, i.e., mapping hardware samples to corresponding basic blocks. In the context of pseudo probes, we much focus on mapping samples back to source-level blocks which is the input to the optimizer. Therefore we are building a

On Fri, Aug 7, 2020 at 11:28 PM Hongtao Yu <hoy at fb.com> wrote: > A few add-ons. > > > > *From: *Wenlei He <wenlei at fb.com> > *Date: *Friday, August 7, 2020 at 10:34 PM > *To: *Xinliang David Li <davidxl at google.com> > *Cc: *"llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, Wei Mi < > wmi at

In addition to an IR block id or probe Id, we’ll also need to know the inline context of a probe if it comes from an inlinee. The current pseudo probe encoding is based on a DFS walk of the inline tree. A MIR BB may contain probes from different inlinees, and we may need to extend the BB-info format for encode the inline contexts there. I’m happy to work with you on a encoding format that can be

Also see my replies inline. From: Hongtao Yu <hoy at fb.com> Date: Saturday, August 8, 2020 at 11:25 AM To: Xinliang David Li <davidxl at google.com> Cc: Wenlei He <wenlei at fb.com>, "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, Wei Mi <wmi at google.com> Subject: Re: [RFC] Context-sensitive Sample PGO with Pseudo-Instrumentation Replied

Hi all, Here I include an RFC for control flow sensitive AutoFDO (FS-AFDO). This is a joint work with David Li. Questions and feedback are welcome. Thanks, Rong ============= [RFC] Control Flow Sensitive AutoFDO (FS-AFDO) 1. Motivation AFDO profile is derived from PMU samples from running an earlier build binary. PMU samples are indexed by the IP addresses. An offline tool uses the debug

> > After the basic profile-based transformations are working, I would like to > add new sources of profile. Mainly, I am thinking of implementing Auto > FDO. > For those who are not familiar with what autoFDO is -- Auto FDO is originally called Sample Based FDO. Its main author is Dehao Chen @google, and Robert Hundt is the one of the main pushers of technology in Google. The

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

I am looking for advice on a problem observed with -fprofile-sample-use for samples built with the AutoFDO tool I took the "hmmer" benchmark out of SPEC2006 It is initially compiled clnag++ -o hmmer -O3 -std=gnu89 -DSPEC_CPU -DNDEBUG -fno-strict-aliasing -w -g *.c This baseline binary runs in about 164.2 seconds as reported by "perf stat" We build a sample file from this

On Wed, Sep 9, 2020 at 9:23 PM Wenlei He via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think calling PGSO size opt is probably a bit misleading though. It’s > more of an adaptive opt strategy, and it can improve performance too due to > better locality. We have something similar internally for selecting opt > level based on profile hotness too under AutoFDO. > >

Hello! (+cc Adam Nemet, since he presented on optimization remarks at LLVM Dev Mtg 2016) I have a large C++ program, which I am compiling using a sampling profile generated via perf and AutoFDO. I'd like to use this profile in order to show the hotness of each code path that is displayed in the new optimization remarks viewer tool ( https://www.youtube.com/watch?v=qq0q1hfzidg). It seems,

On Fri, Aug 12, 2016 at 12:15 PM, Xinliang David Li via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +dehao. > > There are two potential problems: > > 1) the branch gets eliminated in the binary that is being profiled, so > there is no profile data > This seems like a fundamental problem for PGO. Maybe it is also responsible for this bug:

FYI David is referring to PGSO (profile-guided size optimization) as it exists directly under that name, see: https://reviews.llvm.org/D67120. And yeah using PGSO is selecting optsize while this change is selecting optnone. On 9/9/20, 10:58 AM, "llvm-dev on behalf of Tobias Hieta via llvm-dev" <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org> on

Apple folks are also gearing up to push on the PGO front. We are primarily interested in using instrumentation, rather than sampling, to collect profile info. However, I suspect the way profile ended up being used in the various optimization and codegen passes would be largely similar. There is also some interests in pursuing profile directed specialization. But that can wait. I think it makes

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

Michael Spencer via llvm-dev <llvm-dev at lists.llvm.org> writes: > I've recently implemented profile guided section layout in llvm + lld using > the Call-Chain Clustering (C³) heuristic from > https://research.fb.com/wp-content/uploads/2017/01/cgo2017-hfsort-final1.pdf > . In the programs I've tested it on I've gotten from 0% to 5% performance > improvement over

On Sat, Aug 8, 2015 at 6:31 AM, Xinliang David Li <davidxl at google.com> wrote: > On Fri, Aug 7, 2015 at 10:56 PM, Sean Silva <chisophugis at gmail.com> wrote: > > Accidentally sent to uiuc server. > > > > > > On Fri, Aug 7, 2015 at 10:49 PM, Sean Silva <chisophugis at gmail.com> > wrote: > >> > >> Can you compare your results

On Sat, Jul 4, 2020 at 11:28 PM Wenlei He <wenlei at fb.com> wrote: > This sounds very useful. We’ve improved and used memoro > <https://www.youtube.com/watch?v=fm47XsATelI> for memory profiling and > analysis, and we are also looking for ways to leverage memory profile for > PGO/FDO. I think having a common profiling infrastructure for analysis > tooling as well as

Accidentally sent to uiuc server. On Fri, Aug 7, 2015 at 10:49 PM, Sean Silva <chisophugis at gmail.com> wrote: > Can you compare your results with another approach: simply do not > instrument the top 1% hottest functions (by function entry count)? If this > simple approach provides most of the benefits (my measurements on one > codebase I tested show that it would eliminate