similar to: [RFC] Control Flow Sensitive AutoFDO (FS-AFDO)

Hi Rong, This is a very interesting proposal. We've also observed profile quality degradation from CFG destructive pass like loop rotate, and I can see how this proposal would help improve quality of profile that drives later optimization passes in the pipeline. I have a few questions. * How does this affect today's AutoFDO? Specifically, can users upgrade compiler with FS-AutoFDO

In many cases, the line-table fussing to improve autoFDO/sample-PGO would also likely help the debugging experience for optimized code, certainly in cases where line attribution is inherently ambiguous. In those cases, I have no problem with Just Doing It. Something likely to pad the line table to benefit profiling without similarly benefiting debugging… that's probably worth inventing a

Discussed with Hal, Adrain and Paul offline at the llvm dev meeting today. * trip count is not enough for vectorization, there is runtime check that might go false, which can be reflected in profile that we may want to preserve. * simply recording these context-profile may cause problems to iterative-sample-pgo. i.e. when you find a loop's vectorized version no executed (due to runtime

----- Original Message ----- > From: "Dehao Chen" <dehao at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Xinliang David Li" > <davidxl at google.com> > Sent: Tuesday, November 1, 2016 6:41:29 PM > Subject: Re: [llvm-dev] (RFC) Encoding code duplication factor in

----- Original Message ----- > From: "Dehao Chen" <dehao at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Xinliang David Li" > <davidxl at google.com> > Sent: Tuesday, November 1, 2016 8:24:30 PM > Subject: Re: [llvm-dev] (RFC) Encoding code duplication factor in

----- Original Message ----- > From: "Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Dehao Chen" <dehao at google.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Xinliang David Li" > <davidxl at google.com> > Sent: Tuesday, November 1, 2016 4:26:17 PM > Subject: Re: [llvm-dev] (RFC) Encoding code

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

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,

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

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

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

Is there prior art for this sort of thing (in GCC, for example) - I take it this isn't the first time this has come up as a problem for profile accuracy? (so it'd be helpful to know prior solutions to this (& if we're not doing whatever was done before, what it is about our situation that's different, etc), or why it hasn't been a problem, etc) On Thu, Oct 27, 2016 at

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

Motivation: Many optimizations duplicate code. E.g. loop unroller duplicates the loop body, GVN duplicates computation, etc. The duplicated code will share the same debug info with the original code. For SamplePGO, the debug info is used to present the profile. Code duplication will affect profile accuracy. Taking loop unrolling for example: #1 foo(); #2 for (i = 0; i < N; i++) { #3 bar();

----- Original Message ----- > From: "Andrea Di Biagio" <andrea.dibiagio at gmail.com> > To: "Paul Robinson" <paul.robinson at sony.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "David Blaikie" > <dblaikie at gmail.com>, llvm-dev at lists.llvm.org > Sent: Thursday, December 15, 2016 9:05:00 AM > Subject: Re:

The impact to debug_line is actually not small. I only implemented the part 1 (encoding duplication factor) for loop unrolling and loop vectorization. The debug_line size overhead for "-O2 -g1" binary of speccpu C/C++ benchmarks: 433.milc 23.59% 444.namd 6.25% 447.dealII 8.43% 450.soplex 2.41% 453.povray 5.40% 470.lbm 0.00% 482.sphinx3 7.10% 400.perlbench 2.77% 401.bzip2 9.62% 403.gcc

Do you have an estimate of the debug_line size increase? I guess it will be small. David On Thu, Oct 27, 2016 at 11:39 AM, Dehao Chen <dehao at google.com> wrote: > Motivation: > Many optimizations duplicate code. E.g. loop unroller duplicates the loop > body, GVN duplicates computation, etc. The duplicated code will share the > same debug info with the original code. For

On Wed, Dec 7, 2016 at 3:39 PM, Robinson, Paul via llvm-dev < llvm-dev at lists.llvm.org> wrote: > >> I don't know what the right, if any, solution to this is - but I > >> thought I should bring it up in case you or anyone else wanted to > >> puzzle it over & see if the competing needs/desires might need to be > >> considered. > > One thing

The large percentages are from those tiny benchmarks. If you look at omnetpp (0.52%), and xalanc (1.46%), the increase is small. To get a better average increase, you can sum up total debug_line size before and after and compute percentage accordingly. David On Thu, Oct 27, 2016 at 1:11 PM, Dehao Chen <dehao at google.com> wrote: > The impact to debug_line is actually not small. I only