similar to: [LLVMdev] RFC - Improvements to PGO profile support

> On Feb 24, 2015, at 3:31 PM, Diego Novillo <dnovillo at google.com> 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 are still not present in LLVM (e.g., the inliner) but we will

> On Mar 2, 2015, at 4:19 PM, Diego Novillo <dnovillo at google.com> wrote: > > On Thu, Feb 26, 2015 at 6:54 PM, Diego Novillo <dnovillo at google.com <mailto:dnovillo at google.com>> wrote: > > I've created a few bugzilla issues with details of some of the things I'll be looking into. I'm not yet done wordsmithing the overall design document.

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 03/10/2015 10:14 AM, Diego Novillo wrote: > > > On Thu, Mar 5, 2015 at 11:29 AM, Bob Wilson <bob.wilson at apple.com > <mailto:bob.wilson at apple.com>> wrote: > > >> On Mar 2, 2015, at 4:19 PM, Diego Novillo <dnovillo at google.com >> <mailto:dnovillo at google.com>> wrote: >> >> On Thu, Feb 26, 2015 at 6:54 PM,

> On Mar 24, 2015, at 10:27 AM, Xinliang David Li <davidxl at google.com> wrote: > > Diego and I have discussed this according to the feedback received. We > have revised plan for this (see Diego's last reply). Here is a more > detailed re-cap: > > 1) keep MD_prof definition as it is today; also keep using the > frequency propagation as it is (assuming programs

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

Folks, I've created a few bugzilla issues with details of some of the things I'll be looking into. I'm not yet done wordsmithing the overall design document. I'll try to finish it by early next week at the latest. In the meantime, these are the specific bugzilla issues I've opened: 22716 <http://llvm.org/bugs/show_bug.cgi?id=22716>librarieGlobal A dnovillo at

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 Mar 24, 2015, at 12:08 PM, Xinliang David Li <davidxl at google.com> wrote: > > On Tue, Mar 24, 2015 at 10:54 AM, Bob Wilson <bob.wilson at apple.com> wrote: >> >>> On Mar 24, 2015, at 10:53 AM, Diego Novillo <dnovillo at google.com> wrote: >>> >>> On Tue, Mar 24, 2015 at 1:48 PM, Bob Wilson <bob.wilson at apple.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 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 >>

Dehao and I have been discussing changes we need to make to SamplePGO to make it more effective. Currently, SamplePGO is a scalar pass that limits itself to add branch weight annotations. It runs pretty early in the pipeline, so this is fine for other scalar passes that want to use profile data (block layout and regalloc). However, it does nothing to help module passes. Notably, the inliner.

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

> On Mar 24, 2015, at 3:22 PM, Xinliang David Li <davidxl at google.com> wrote: > > On Tue, Mar 24, 2015 at 2:47 PM, Bob Wilson <bob.wilson at apple.com <mailto:bob.wilson at apple.com>> wrote: >> >>> On Mar 24, 2015, at 12:08 PM, Xinliang David Li <davidxl at google.com> wrote: >>> >>> On Tue, Mar 24, 2015 at 10:54 AM, Bob

On Fri, Apr 24, 2015 at 12:29 PM, Diego Novillo <dnovillo at google.com> wrote: > > > On Fri, Apr 24, 2015 at 3:28 PM, Xinliang David Li <davidxl at google.com> > wrote: >> >> yes -- for count representation, 64 bit is needed. The branch weight >> here is different and does not needs to be 64bit to represent branch >> probability precisely. > >

> On Mar 24, 2015, at 10:53 AM, Diego Novillo <dnovillo at google.com> wrote: > > On Tue, Mar 24, 2015 at 1:48 PM, Bob Wilson <bob.wilson at apple.com> wrote: >> >>> On Mar 24, 2015, at 10:27 AM, Xinliang David Li <davidxl at google.com> wrote: >>> >>> 2.3) remove the 'laplace rule of succession' which can be very harmful

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

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

Can you tell us if you're continuing to use the same approach as described in one of the LLVM meetings, i.e. instrument at the clang AST level? Also, do you generate GCOV files, some yaml, or is this a separate format? And finally in the meeting you had given how you assign counters to the blocks, an algorithm to minimize the number of insertions. Is that algorithm a well-known one or a