similar to: [LLVMdev] RFC - Profile Guided Optimization in LLVM

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

On 2013-06-15 14:18 , Evan Cheng wrote: > 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. > Excellent! We are initially

On Jun 17, 2013, at 6:54 AM, Diego Novillo <dnovillo at google.com> wrote: > On 2013-06-15 14:18 , Evan Cheng wrote: >> 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

On Jun 12, 2013, at 2:23 PM, Diego Novillo <dnovillo at google.com> wrote: > In terms of optimizations, our (Google) experience is that > inlining is the key beneficiary of profile information. > Particularly, in big C++ applications. I expect to focus most > of my attention on the inliner. That sounds plausible to me. It seems like we might need a way of representing call

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

On Wed, Jun 12, 2013 at 2:55 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > That sounds plausible to me. It seems like we might need a way of > representing call graph profiling in addition to the existing branch > probabilities? > Agreed. An important consideration here is WPO vs. LTO vs. TU-at-a-time call graphs. > FWIW, the greedy register allocator’s live range

On Wed, Feb 25, 2015 at 10:52 AM, Philip Reames <listmail at philipreames.com> wrote: > On 02/24/2015 03:31 PM, Diego Novillo wrote: > > > We (Google) have started to look more closely at the profiling > infrastructure in LLVM. Internally, we have a large dependency on PGO to get > peak performance in generated code. > > Some of the dependencies we have on profiling

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 2015 May 27, at 07:42, Diego Novillo <dnovillo at google.com> wrote: > > On Tue, May 26, 2015 at 11:47 PM, Lee Hunt <leehu at exchange.microsoft.com> wrote: > >> For example, from reading different pages on how Clang PGO, it’s unclear if >> it does “block reordering” (i.e. moving unexecuted code blocks to a distant >> code page, leaving only ‘hot’

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

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

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 05/27/2015 11:13 AM, Duncan P. N. Exon Smith wrote: >> On 2015 May 27, at 07:42, Diego Novillo <dnovillo at google.com> wrote: >> >> On Tue, May 26, 2015 at 11:47 PM, Lee Hunt <leehu at exchange.microsoft.com> wrote: >> >>> For example, from reading different pages on how Clang PGO, it’s unclear if >>> it does “block reordering” (i.e. moving

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

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 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 Tue, Jun 18, 2013 at 11:19 AM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jun 17, 2013, at 6:54 AM, Diego Novillo <dnovillo at google.com> wrote: > >> On 2013-06-15 14:18 , Evan Cheng wrote: >>> 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.

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

Hello - I'm an Engineer in Microsoft Office after looking into possible advantages of using PGO for our Android Applications. We at Microsoft have deep experience with Visual C++'s Profile Guided Optimization<https://msdn.microsoft.com/en-us/library/e7k32f4k.aspx> and often see 10% or more reduction in the size of application code loaded after using PGO for key scenarios (e.g.

Hi all, To implement more profile-guided optimizations, we’d like to use ProfileSummaryInfo (PSI) and BlockFrequencyInfo (BFI) from more passes of various types, under the new pass manager. The following is what we came up with. Would appreciate feedback. Thanks. Issue It’s not obvious (to me) how to best do this, given that we cannot request an outer-scope analysis result from an inner-scope