similar to: [LLVMdev] RFC: Callee speedup estimation in inline cost analysis

Just nitpicking: 1) DI(F) should include a component that estimate the epi/prologue cost (frameSetupCost) which InlinedDF does not have 2) The speedup should include callsite cost associated with 'C' (call instr, argument passing): Speedup(F,C) = (DI(F) + CallCost(C) - InlinedDF(F,C))/DI(F). Otherwise the proposal looks reasonable to me. David On Thu, Jul 30, 2015 at 2:25 PM,

Functions in LLVM IR have a function_entry_count metadata that is attached in PGO compilation. By using the entry count together with the block frequency info, the compiler computes the profile count of call instructions based on which the hotness/coldness of callsites can be determined. Experiments have shown that using a higher threshold for hot callsites results in improved runtime performance

Hi, I browsed the LLVM inliner implementation, and it seems there is room for improvement. (I have not read it too carefully, so correct me if what I observed is wrong). First the good side of the inliner -- the function level summary and inline cost estimation is more elaborate and complete than gcc. For instance, it considers callsite arguments and the effects of optimization enabled by

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

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

IMO, the appropriate thing for TTI to inform the inliner about is how costly the actual act of a "call" is likely to be. I would hope that this would only be used on targets where there is some really dramatic overhead of actually doing a function call such that the code size cost incurred by inlining is completely dwarfed by the improvements. GPUs are one of the few platforms that

> 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

IMO, a good inliner with a precise cost/benefit model will eventually need what Art is proposing here. Giving the function call overhead as an example. It depends on a couple of factors: 1) call/return instruction latency; 2) function epilogue/prologue; 3) calling convention (argument parsing, using registers or not, what register classes etc). All these factors depend on target information. If

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

On Nov 23, 2010, at 5:07 PM, Xinliang David Li wrote: > Hi, I browsed the LLVM inliner implementation, and it seems there is room for improvement. (I have not read it too carefully, so correct me if what I observed is wrong). > > First the good side of the inliner -- the function level summary and inline cost estimation is more elaborate and complete than gcc. For instance, it considers

On Fri, Dec 15, 2017 at 12:22 AM, Sean Silva <chisophugis at gmail.com> wrote: > IIUC, this proposal is just saying that we should infer a static profile > for entry counts just like we do for branch probabilities. In the case of > entry counts, we do not hide that information behind an analysis like BPI, > so currently just annotating synthetic PGO entry counts is a simple >

Instrumentation based Profile Guided Optimization (PGO) is a compiler technique that leverages important program runtime information, such as precise edge counts and frequent value information, to make frequently executed code run faster. It's proven to be one of the most effective ways to improve program performance. An important design point of PGO is to decide where to place the

On Tue, Nov 23, 2010 at 8:07 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > Hi, I browsed the LLVM inliner implementation, and it seems there is room > for improvement.  (I have not read it too carefully, so correct me if what I > observed is wrong). > First the good side of the inliner -- the function level summary and inline > cost estimation is more elaborate and

> On Mar 10, 2016, at 10:34 AM, Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Thu, Mar 10, 2016 at 6:49 AM, Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote: > IMO, the appropriate thing for TTI to inform the inliner about is how costly the actual act of a "call" is likely to be. I

On Fri, Dec 15, 2017 at 11:13 AM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Fri, Dec 15, 2017 at 10:22 AM, Easwaran Raman <eraman at google.com> > wrote: > >> >> >> On Fri, Dec 15, 2017 at 12:22 AM, Sean Silva <chisophugis at gmail.com> >> wrote: >> >>> IIUC, this proposal is just saying that we should infer a

Hello, My team and I noticed that callsite hotness information is not preserved from compile to link step with LTO/thinLTO enabled. As a result, the link step inlining pass remains conservative when inlining callsites known to be hot (ie. without the 'HotCallSiteThreshold' which is set at 3000 by default). There are likely many cross-module inlining opportunities lost this way, and

Xinliang David Li wrote: > Hi, I browsed the LLVM inliner implementation, and it seems there is > room for improvement. (I have not read it too carefully, so correct me > if what I observed is wrong). > > First the good side of the inliner -- the function level summary and > inline cost estimation is more elaborate and complete than gcc. For > instance, it considers callsite

RFC: Inlining Report Motivation Making good inlining choices while optimizing an application is often key to achieving optimal performance. While the compiler's default inlining heuristics sometimes provide great out-of-box results, optimal performance is sometimes achieved only after varying the settings of certain compiler options related to inlining or adding "always_inline" or

On Fri, Dec 15, 2017 at 11:56 AM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Fri, Dec 15, 2017 at 11:27 AM, Xinliang David Li <davidxl at google.com> > wrote: > >> >> >> On Fri, Dec 15, 2017 at 11:13 AM, Sean Silva <chisophugis at gmail.com> >> wrote: >> >>> >>> >>> On Fri, Dec 15, 2017 at 10:22