similar to: [RFC] Enable Partial Inliner by default

Hi Graham, Thank you for offering help. I am trying to create a reproducer. The problem is that the crashes happen whilst LTO is used. One thing I am sure about IR is broken at compile time. Thanks, Evgeny From: Graham Yiu <gyiu at ca.ibm.com> Date: Friday, 10 November 2017 at 16:09 To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> Cc: "junbuml at codeaurora.org"

Hi Evgeny, I just realized that if these are compile-time errors I can help investigate on my end. Do you have something I can use to reproduce? Cheers, Graham Yiu LLVM Compiler Development IBM Toronto Software Lab Office: (905) 413-4077 C2-707/8200/Markham Email: gyiu at ca.ibm.com From: Graham Yiu/Toronto/IBM To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> Cc:

Hi Graham, I created a bug report with a reproducer for the failures I’ve got: https://bugs.llvm.org/show_bug.cgi?id=35288 I have also found that LTO reverts everything the partial inliner has done. Maybe the partial inliner should not be used at the first LTO phase (compilation). I hope I’ll have a chance to look at the code size regressions this week. Thanks, Evgeny Astigeevich From:

Hello All, This conversations seems to have fizzled out and I would like to try to revive it. My intention is to pick up where Graham left off with enabling partial-inlining by default. On Sat, Dec 9, 2017 at 7:47 AM, Florian Hahn via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On 13/11/2017 14:47, Evgeny Astigeevich via llvm-dev wrote: > >> Hi Graham,

Hi Sean, Thank you for reminding me. It looks like it get lost among tons of emails and other tasks. I’ll check if the code size issues still exist. Thanks, Evgeny Astigeevich From: Sean Fertile <sd.fertile at gmail.com> Date: Monday, 29 January 2018 at 19:52 To: Florian Hahn <Florian.Hahn at arm.com> Cc: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>, Graham Yiu <gyiu

Hi Graham, Thanks for sharing this. Are you planning on enabling the pass only on PGO? Even in non-PGO, I noticed some performance gains when we are aggressive in partially inlining the early return part, especially when the callee spill CSRs in the entry block. At a high level, I have two questions: 1. What is the main obstacle that prevent the pass from being enabled by default? 2.

Hi, I noticed some performance gains in some spec benchmarks without significant code size bloat when aggressively performing partial inlining, especially when the original callee spill CSRs in the entry block. I guess the partial inlining is not enabled mainly due to the code size. Is there any other issue which prevent the pass from being enabled? Do we have any plan or any on-going works

Thanks Easwaran. This is what we've observed as well, where the old PM inliner was only looking hot/cold callee information, which have signficantly smaller boosts/penalties compared to callsite information. Teresa, do you know if there is some documentation/video/presentation on how PGO information is represented in LLVM and what information is passed via the IR? I'm finding some

Hi Teresa, Actually, enabling the new pass manager manually seems to have solved this issue, so this problem is only valid for the old pass manager. Thanks, Graham Yiu LLVM Compiler Development IBM Toronto Software Lab Office: (905) 413-4077 C2-707/8200/Markham Email: gyiu at ca.ibm.com From: Teresa Johnson <tejohnson at google.com> To: Graham Yiu <gyiu at ca.ibm.com> Cc:

On Tue, Oct 3, 2017 at 1:46 PM, Teresa Johnson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Tue, Oct 3, 2017 at 1:38 PM, Graham Yiu <gyiu at ca.ibm.com> wrote: > >> Hi Teresa, >> >> Actually, enabling the new pass manager manually seems to have solved >> this issue, so this problem is only valid for the old pass manager. >> >

I second the fact that a way to outline specific function regions independently of the partial inliner sound very useful. I am not sure however if we would want a mode within the partialInliner or something completely independent. As a general question, does anybody has a clear idea of what are the constraints on the region CodeExtractor is currently able to handle ? Going through the code, it

Hi David, The only reason I can see to use the 'pattern matching' part as a fall-back is in case we cannot inline the (what I'm assuming would be) a much bigger hot-path-only cloned function for whatever reason. What I'm assuming here is that after cold-region outlining, we may still have a large portion of the original function body to attempt to inline, whereas the pattern

Hi Evgeny, I know of the current machine outliner in LLVM. If you look in the "More detailed performance data" in the end section it includes performance comparisons to the machine outliner. As for the algorithmic approach they are kind of similar. Machine Outliner: - Builds a suffix tree based on identical equivalence between machine instrs. - Uses target specific cost model for

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

Hi David, So I've began doing some implementation on the outlining portion of the code. Currently, I got the partial inliner to outline cold regions (single entry, single exit) of the code, based solely on the existence of ProfileSummaryInfo (ie. profiling data). However, I have some concerns on how this will co-exist with the existing code that peels early returns. The control flow looks

Hello, My team and I are looking to do some enhancements in the partial inliner in opt. Would appreciate any feedback that folks might have. # Partial Inlining in LLVM opt ## Summary ### Background Currently, the partial inliner searches the first few blocks of the callee and looks for a branch to the return block (ie. early return). If found, it attempts to outline the rest of the

On 10/25/2017 12:32 PM, Evgeny Astigeevich wrote: > > Hi Hal, > > I quickly checked the execution profile. It is real. The code changed > significantly. A number of the hottest regions changed. I’ll compare IRs. > Thanks. Obviously a 1000% execution performance regression seems problematic. -Hal > JFYI FreeBench/fourinarow time graph: >

On Tue, Oct 3, 2017 at 12:08 PM, Davide Italiano <davide at freebsd.org> wrote: > On Tue, Oct 3, 2017 at 11:57 AM, Graham Yiu via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hello, >> >> I recently noticed that the new pass manager was not enabled at regular/thin >> LTO link step even if '-fexperimental-new-pass-manager' was specified in the

Hi Jessica, Thanks for the feedback. I believe the existing partial inliner pass does use some common utilities like the code extractor to do outlining. Is that what you're referring to? I don't recall seeing any other passes that has outlining other than the machine outliner, but I may have missed something. I briefly looked at River's RFC and it seems he's mainly utilizing

Based on function names and structures, this is some version of GCC :) Any way you can post the entire .ll file? Because it's globalsmodref, it's hard to debug without the other functions, since it goes over all the functions to determine address takenness, etc :) On Tue, Jul 21, 2015 at 3:23 PM, Michael Zolotukhin <mzolotukhin at apple.com> wrote: > Hi Chandler, > > We