similar to: Enable new inline cost heuristic for switch

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.

On 2017-11-17 13:10, Quentin Colombet wrote: >> On Nov 16, 2017, at 2:31 PM, junbuml at codeaurora.org wrote: >> On 2017-11-14 17:22, Quentin Colombet wrote: >> >>> Hi, >>> I think it is kind of artificial to tie the CSRCost with the >>> presence >>> of calls. >>> I think I’ve already mentioned it in one of the review, but I

On 2017-11-14 17:22, Quentin Colombet wrote: > Hi, > > I think it is kind of artificial to tie the CSRCost with the presence > of calls. > I think I’ve already mentioned it in one of the review, but I > believe it would be better to differentiate when we want to use a CSR > to avoid spilling or to avoid splitting. CSR instead of spilling is > good, CSR instead of

On 2017-11-10 07:47, Nemanja Ivanovic wrote: > One thing I thought about doing a while back and never really wrote a > POC for is the following: > - Make FirstCSRCost a property of the MachineBasicBlock (or create a > map of MBB* -> FirstCSRCost) > > - Implement a pre-RA pass that will populate the map as follows: > > - Identify all blocks with calls > > -

On 2016-08-26 12:47, Mehdi Amini wrote: >> On Aug 26, 2016, at 9:06 AM, junbuml at codeaurora.org wrote: >> >> On 2016-08-26 11:32, Mehdi Amini wrote: >>> Hi, >>>> Recently, I noticed that less number of global variables are merged >>>> in global-merge pass and in some global variable, array types are >>>> used instead of its

On 2018-02-22 11:14, gberry at codeaurora.org wrote: > FROM: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] ON BEHALF OF > Jun Lim via llvm-dev > SENT: Thursday, February 22, 2018 11:05 AM > > Hi All, > > I found some cases where a spill of a live range in a block is > reloaded only in one of its successors, and there is no reload in > other paths through other

On 2017-10-30 21:20, Hal Finkel wrote: > On 10/30/2017 12:20 PM, junbuml at codeaurora.org wrote: >> On 2017-10-27 19:50, Hal Finkel wrote: >>> On 10/27/2017 03:32 PM, Jun Lim via llvm-dev wrote: >>> >>>> When compiling C code below for AArach64, I saw that shrink-wrapping >>>> didn't happen due to the very early uses of CSRs in the entry

On 2017-10-27 19:50, Hal Finkel wrote: > On 10/27/2017 03:32 PM, Jun Lim via llvm-dev wrote: > >> When compiling C code below for AArach64, I saw that shrink-wrapping >> didn't happen due to the very early uses of CSRs in the entry block. >> So CSR spills/reloads are executed even when the early exit block is >> taken. >> >> int getI(int i); >>

Thanks for the test case! I can reproduce this, and see with the compiler I saved from just before r278338 that this is indeed a chance in behavior. Looking at why this changed... On Fri, Aug 26, 2016 at 1:42 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> On Aug 26, 2016, at 1:34 PM, junbuml at codeaurora.org wrote: >> >> On 2016-08-26 12:47, Mehdi Amini wrote:

> From: junbuml at codeaurora.org [mailto:junbuml at codeaurora.org] > Sent: Thursday, February 22, 2018 11:39 AM > > On 2018-02-22 11:14, gberry at codeaurora.org wrote: > > FROM: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] ON BEHALF OF > > Jun Lim via llvm-dev > > SENT: Thursday, February 22, 2018 11:05 AM > > > > Hi All, > > > > I

> On Aug 26, 2016, at 2:06 PM, Teresa Johnson <tejohnson at google.com> wrote: > > Mehdi: I see what is going on: > > + ArrayType *Ty = > + ArrayType::get(Type::getInt8Ty(RegularLTO.Ctx), I.second.Size); > + GlobalVariable *OldGV = RegularLTO.CombinedModule->getNamedGlobal(I.first); > + if (OldGV && OldGV->getType()->getElementType()

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"

On 2016-08-26 11:32, Mehdi Amini wrote: > Hi, > >> Recently, I noticed that less number of global variables are merged in >> global-merge pass and in some global variable, array types are used >> instead of its original type. For example, [4xi8] with align 4 is used >> for a i32 global variable. For me, it seems that such pattern is >> observed after

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

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

On 2018-02-22 16:21, Roman Lebedev wrote: > On Fri, Feb 23, 2018 at 12:15 AM, Jun Lim via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> For the example code below, >> int L = M + 10; >> for (k = 1 ; k <=L; k++) { >> dummy(); >> if (k < M) >> dummy2(); >> } >> , we can split the loop into two parts like :

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

Hi Chris, It did compile when I gave that option. But it gives me an error when I try to run the executable on an Intel machine. ----- 1513158 is not prime. Exception handler needed, but not enabled. Recompile program with -enable-correct-eh-support. lli[0x8429bb4] lli[0x8429dc0] /lib/libc.so.6[0x40128c18] /lib/libc.so.6(abort+0x161)[0x40129cb5] [0x403da922] ../../../i386: line 4: 27606