Displaying 20 results from an estimated 20000 matches similar to: "[RFC] Enhance Partial Inliner by using a general outlining scheme for cold blocks"
2017 Aug 24
3
[RFC] Enhance Partial Inliner by using a general outlining scheme for cold blocks
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
2017 Aug 29
3
[RFC] Enhance Partial Inliner by using a general outlining scheme for cold blocks
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
2017 Aug 24
1
[RFC] Enhance Partial Inliner by using a general outlining scheme for cold blocks
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
2017 Aug 15
3
[RFC] Enhance Partial Inliner by using a general outlining scheme for cold blocks
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
2017 Aug 15
2
[RFC] Enhance Partial Inliner by using a general outlining scheme for cold blocks
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
2017 Nov 02
13
[RFC] Enable Partial Inliner by default
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]
2017 Nov 10
5
[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"
2017 Nov 10
0
[RFC] Enable Partial Inliner by default
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:
2017 Oct 03
2
PGO information at LTO/thinLTO link step
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
2017 Oct 03
2
PGO information at LTO/thinLTO link step
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.
>>
>
2017 Oct 03
2
PGO information at LTO/thinLTO link step
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:
2017 Oct 03
3
PGO information at LTO/thinLTO link step
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
2017 Oct 03
5
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.
2017 Sep 13
2
General question about enabling partial inlining
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
2017 Oct 03
2
New Pass Manager with flto[=thin] not enabled (??)
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
2018 Jan 29
2
[RFC] Enable Partial Inliner by default
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,
2017 Nov 13
2
[RFC] Enable Partial Inliner by default
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:
2018 Jan 29
0
[RFC] Enable Partial Inliner by default
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
2017 Jul 26
2
[RFC] Add IR level interprocedural outliner for code size.
2017-07-26 9:31 GMT-07:00 Quentin Colombet <qcolombet at apple.com>:
>
> On Jul 25, 2017, at 10:36 PM, Mehdi AMINI <joker.eph at gmail.com> wrote:
>
>
>
> 2017-07-24 16:14 GMT-07:00 Quentin Colombet via llvm-dev <
> llvm-dev at lists.llvm.org>:
>
>> Hi River,
>>
>> On Jul 24, 2017, at 2:36 PM, River Riddle <riddleriver at
2017 Jul 26
4
[RFC] Add IR level interprocedural outliner for code size.
2017-07-24 16:14 GMT-07:00 Quentin Colombet via llvm-dev <
llvm-dev at lists.llvm.org>:
> Hi River,
>
> On Jul 24, 2017, at 2:36 PM, River Riddle <riddleriver at gmail.com> wrote:
>
> Hi Quentin,
> I appreciate the feedback. When I reference the cost of Target Hooks it's
> mainly for maintainability and cost on a target author. We want to keep the
>