similar to: General question about enabling partial inlining

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.

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

Forgot to add that all experiments were done with '-O3 -m64 -fexperimental-new-pass-manager'. 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: llvm-dev at lists.llvm.org Cc: junbuml at codeaurora.org, xinliangli at gmail.com Date: 11/02/2017 05:26 PM Subject: [RFC]

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:

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:

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

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

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

-- The C compiler identification is GNU 7.3.1 -- The CXX compiler identification is GNU 7.3.1 According to buildbot log here http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/37730/steps/cmake%20stage%201/logs/stdio for Simon's example ICE. Best, Jinsong Ji (纪金松), PhD. XL/LLVM on Power Compiler Development E-mail: jji at us.ibm.com From: "Finkel, Hal J. via

Hi Nicholas, The admin of the buildbot is aware of this, will handle it after long weekend. Thanks. Best, Jinsong Ji (纪金松), PhD. XL/LLVM on Power Compiler Development E-mail: jji at us.ibm.com From: Nicholas Krause <xerofoify at gmail.com> To: Jinsong Ji <jji at us.ibm.com>, "Finkel, Hal J." <hfinkel at anl.gov> Cc: "llvm-dev at lists.llvm.org"

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

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:

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

On Tue, Aug 15, 2017 at 4:14 PM, River Riddle via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hey Graham, > I worked on pretty much this exact thing last year. I did something > similar to what you described, I traversed the CFG and built potentially > profitable regions from any given valid start node. At that point there > were several road blocks that prevented it

http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/37730/ is an example of the ICE when D64146/rL370584 landed. On 01/09/2019 02:23, Florian Hahn via llvm-dev wrote: > Hi, > >> On Aug 31, 2019, at 15:14, Nandor Licker via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hello PowerPC fans, >> >> I am attempting to land D64146 and the PowerPC

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,