similar to: (RFC) Encoding code duplication factor in discriminator

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

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

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

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

Hi Dehao, This is definitely an important problem, thanks for writing this up! There is a related problem that I think we can address at the same time: When we multiversion code, for example when we use runtime checks to enable the creation of a vectorized loop while retaining the scalar loop, and then we collect profiling data, we should be able to recover the relative running time of the

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

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

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

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

damn... my english is not readable at all when I try to write fast... trying to make some clarification below, hopefully can make it more readable... On Tue, Nov 1, 2016 at 2:07 PM, Dehao Chen <dehao at google.com> wrote: > Oops... pressed the wrong button and sent out early... > > On Tue, Nov 1, 2016 at 2:01 PM, Dehao Chen <dehao at google.com> wrote: > >> If

If Hal's proposal is for SamplePGO purpose, let me clarify some design principles of SamplePGO. The profile for sample pgo uses source location as the key to map the execution count back to IR. This design is based on the principle that we do not want the profile to be tightly couple with compiler IR. Instead, profile is simple an attribute of the source code. We have been benefited a lot

It looks like the example doesn't use the encoding described in the text? Assume that the discriminator is uint32. The traditional discriminator is less than 256, let's take 8 bit for it. For duplication factor (type 1 duplication), we assume the maximum unroll_factor * vectorize_factor is less than 256, thus 8 bit for it. For unique number(type 2 duplication), we assume code is at most

As illustrated in the above example, it is not like "vectorization has a distinct bit". All different optimizations make clones of code which will be labeled by UIDs represented by N (e.g. 8) bits. In this way, the space will be capped by the number of clones all optimizations have made, instead of # of optimizations that has applied. And it will be capped at 2^N-1. The cons of using uid

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

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

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

> On Feb 9, 2017, at 4:09 PM, Robinson, Paul <paul.robinson at sony.com> wrote: > > Sorry to be late to the party, I was out yesterday. > > I do want to point out that there are different motivations for the two cases. When moving/hoisting a single instruction, the motivation is to avoid bad debugger stepping and bad sample-profile data (we get a lot of complaints about