similar to: [LLVMdev] proposal for improving profile info support

Hi,all: My name is Wei Wu and I would like to participate in Google Summer of Code 2011.I'm willing to improve LLVM's support for profile information,follow Bob Wilson's proposal[1].After read his proposal I have some questions below: 1.Is the "__builtin_expect" works now and how to use it? I have searched llvm's trunk and found it in two files

On Jun 1, 2011, at 5:03 PM, Jakub Staszak wrote: > I just found a small bug. Fixed version attached. > > <kuba_bp3.patch> Committed as r132613 (and r132616). Thanks Jakub! To help reviewers understand the patch and where we're headed with it, I've prepared the following design documentation. For now I'm sending it to llvm-dev until we have an official design doc for

Hi Alastair, In addition to your planned tasks, you might want to put in some work to ensure branch probabilities are not lost during optimization. One known issue is LLVM optimizer can turn branchy code into switch statements and it would completely discard probability. Here is a simple example: static void func2(int N, const int *a, const int *b, int *c) __attribute__((always_inline)); void

> 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 Feb 4, 2014, at 4:36 PM, Andrew Trick <atrick at apple.com> wrote: > > On Feb 4, 2014, at 4:07 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> >> On Feb 3, 2014, at 12:13 AM, Andrew Trick <atrick at apple.com> wrote: >> >>> On Feb 2, 2014, at 6:55 PM, Chandler Carruth <chandlerc at gmail.com> wrote: >>>

Hello all, I would like to participate in this year's Google Summer of Code and I am sending you a short description of my proposal. I have written the formal proposal already and if someone is interested I can send him the pdf. One of the open projects in the LLVM list is to enhance LLVM with static profiling capabilities. LLVM already provides a unified structure for writing pro

On Sun, Feb 2, 2014 at 6:18 PM, Andrew Trick <atrick at apple.com> wrote: > > On Feb 2, 2014, at 2:13 AM, Chandler Carruth <chandlerc at gmail.com> wrote: > > > Right now, all profile information is funneled through two analysis > passes prior to any part of the optimizer using it. > > > > First, we have BranchProbabilityInfo, which provides a simple

On Feb 3, 2014, at 12:13 AM, Andrew Trick <atrick at apple.com> wrote: > On Feb 2, 2014, at 6:55 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > >> On Sun, Feb 2, 2014 at 6:18 PM, Andrew Trick <atrick at apple.com> wrote: >> >> On Feb 2, 2014, at 2:13 AM, Chandler Carruth <chandlerc at gmail.com> wrote: >> >> > Right now,

Hi Chandler and Alastair, I have been using the Profile.pl and the related passes and optimizations for about 4 years now. With every new release lately, the support for the profile scripts and their framework seemed to be downgrading. Hence, I used my own tiny one line fixes to keep them working. I offered to send these small patches to keep these scripts working, to the LLVM dev so that others

On Sun, Jul 15, 2012 at 8:32 AM, Alastair Murray <alastairmurray42 at gmail.com > wrote: > Hi Chandler, > > I'm a GSoC student working on profiling support (mentor CC'ed). I'm no > stranger to the issues with the current system: my original proposal was > written without knowledge of the limitations. This is why this list > hasn't heard much from me yet.

On Oct 20, 2011, at 11:53 PM, Chandler Carruth wrote: > On Thu, Oct 20, 2011 at 10:53 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > On Oct 20, 2011, at 9:56 AM, Chandler Carruth wrote: > > > A new patch is attached that is *much* less of a rough draft. Sorry for any confusion due to the early state of the patch. > > Thanks, Chandler. This is great stuff. >

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

Right now, all profile information is funneled through two analysis passes prior to any part of the optimizer using it. First, we have BranchProbabilityInfo, which provides a simple interface to the simplest form of profile information: local and relative branch probabilities. These merely express the likelihood of taking one of a mutually exclusive set of exit paths from a basic block. They are

Ok, I think I have a working pass that is based much more on what we've talked about here. The patch is attached. I'd love to commit it soon-ish and then start tweaking it based on feedback from you, others, and looking at how it actually works in the wild. It's essentially a re-write, so it may be hard to read... Let me know if some other form would be easier. Some responses to your

1. Summary I will implement two optimizations in the LLVM compiler, both based on runtime profile information: an inlining mechanism that takes the call frequency into consideration, and a better basic block placement algorithm. 2. The project LLVM now includes an efficient framework [1] for instrumenting an application and collecting edge and path profile information. Profile-guided

On Thu, May 7, 2015 at 8:43 AM, Bob Wilson <bob.wilson at apple.com> wrote: > >> On May 7, 2015, at 12:55 AM, Hayden Livingston <halivingston at gmail.com> wrote: >> >> 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? > > Yes, that is the

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

On Jun 12, 2013, at 3:05 PM, Chandler Carruth <chandlerc at google.com> wrote: > > 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

Hi all, In light of the expected removal of ProfileInfo this is a request for comments on the next few items that I now plan to work on for GSoC. Planned tasks: #0 Add support for determining branch weight metadata by profiling At the absolute minimum this will require writing a new profile loader which will set branch weight metadata based on profiling data. #1 Optionally use profiling

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 standard PGO with zero cases of slowdowns and up to 15% reduction in ITLB misses. There are