[llvm-dev] [RFC] Enable Partial Inliner by default

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev

Hello,

I'd like to propose turning on the partial inliner (-enable-partial-inlining) by default.

We've seen small gains on SPEC2006/2017 runtimes as well as lnt compile-times with a 2nd stage bootstrap of LLVM. We also saw positive gains on our internal workloads.

-------------------------------------
Brief description of Partial Inlining
-------------------------------------
A pass in opt that runs after the normal inlining pass. Looks for branches to a return block in the entry and immediate successor blocks of a function. If found, it outlines the rest of the function using the CodeExtractor. It then attempts to inline the leftover entry block (and possibly one or more of its successors) to all its callers. This effectively peels the early return block(s) into the caller, which could be executed without incurring the call overhead of the function just to return immediately. Inlining and call overhead cost, as well as branch probabilities of the return block(s) are taken into account before inlining is done. If inlining is not successful, then the changes are discarded.

eg.

void foo() {
bar();
// rest of the code in foo
}

void bar() {
if (X)
return;
// rest of code (to be outlined)
}

After Partial Inlining:

void foo() {
if (!X)
bar.outlined();
// rest of the code in foo
}

void bar.outlined() {
// rest of the code in bar
}


Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode

----------------------------------------------
Runtime performance (speed)
----------------------------------------------
Workload Improvement
-------- -----------
SPEC2006(C/C++) 0.06% (geomean)
SPEC2017(C/C++) 0.10% (geomean)
----------------------------------------------
Compile time performance for Bootstrapped LLVM
----------------------------------------------
Workload Improvement
-------- -----------
SPEC2006(C/C++) 0.41% (cumulative)
SPEC2017(C/C++) -0.16% (cumulative)
lnt 0.61% (geomean)
----------------------------------------------
Compile time performance
----------------------------------------------
Workload Increase
-------- --------
SPEC2006(C/C++) 1.31% (cumulative)
SPEC2017(C/C++) 0.25% (cumulative)
----------------------------------------------
Code size
----------------------------------------------
Workload Increase
-------- --------
SPEC2006(C/C++) 3.90% (geomean)
SPEC2017(C/C++) 1.05% (geomean)

NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark "astar", which increased by 86%. Removing this outlier, we get a more reasonable increase of 0.58%.

NOTE2: There is a patch up for review on Phabricator to enhance the partial inliner with the presence of profiling information (https://reviews.llvm.org/D38190).


Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev

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: [hidden email]


Inactive hide details for Graham Yiu---11/02/2017 05:26:58 PM---Hello, I'd like to propose turning on the partial inliner (-enaGraham Yiu---11/02/2017 05:26:58 PM---Hello, I'd like to propose turning on the partial inliner (-enable-partial-inlining) by default.

From: Graham Yiu/Toronto/IBM
To: [hidden email]
Cc: [hidden email], [hidden email]
Date: 11/02/2017 05:26 PM
Subject: [RFC] Enable Partial Inliner by default




Hello,

I'd like to propose turning on the partial inliner (-enable-partial-inlining) by default.

We've seen small gains on SPEC2006/2017 runtimes as well as lnt compile-times with a 2nd stage bootstrap of LLVM. We also saw positive gains on our internal workloads.

-------------------------------------
Brief description of Partial Inlining
-------------------------------------
A pass in opt that runs after the normal inlining pass. Looks for branches to a return block in the entry and immediate successor blocks of a function. If found, it outlines the rest of the function using the CodeExtractor. It then attempts to inline the leftover entry block (and possibly one or more of its successors) to all its callers. This effectively peels the early return block(s) into the caller, which could be executed without incurring the call overhead of the function just to return immediately. Inlining and call overhead cost, as well as branch probabilities of the return block(s) are taken into account before inlining is done. If inlining is not successful, then the changes are discarded.

eg.

void foo() {
bar();
// rest of the code in foo
}

void bar() {
if (X)
return;
// rest of code (to be outlined)
}

After Partial Inlining:

void foo() {
if (!X)
bar.outlined();
// rest of the code in foo
}

void bar.outlined() {
// rest of the code in bar
}


Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode

----------------------------------------------
Runtime performance (speed)
----------------------------------------------
Workload Improvement
-------- -----------
SPEC2006(C/C++) 0.06% (geomean)
SPEC2017(C/C++) 0.10% (geomean)
----------------------------------------------
Compile time performance for Bootstrapped LLVM
----------------------------------------------
Workload Improvement
-------- -----------
SPEC2006(C/C++) 0.41% (cumulative)
SPEC2017(C/C++) -0.16% (cumulative)
lnt 0.61% (geomean)
----------------------------------------------
Compile time performance
----------------------------------------------
Workload Increase
-------- --------
SPEC2006(C/C++) 1.31% (cumulative)
SPEC2017(C/C++) 0.25% (cumulative)
----------------------------------------------
Code size
----------------------------------------------
Workload Increase
-------- --------
SPEC2006(C/C++) 3.90% (geomean)
SPEC2017(C/C++) 1.05% (geomean)

NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark "astar", which increased by 86%. Removing this outlier, we get a more reasonable increase of 0.58%.

NOTE2: There is a patch up for review on Phabricator to enhance the partial inliner with the presence of profiling information (https://reviews.llvm.org/D38190).


Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]




_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev

Hi Graham,

 

Is your RFC to enable it with the current pass manager? If so, do you have benchmark data for it?

Am I correct the new pass manager turns the partial inliner by default?

 

Thanks,

Evgeny Astigeevich

 

From: llvm-dev <[hidden email]> on behalf of Graham Yiu via llvm-dev <[hidden email]>
Reply-To: Graham Yiu <[hidden email]>
Date: Thursday, 2 November 2017 at 22:05
To: "[hidden email]" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: Re: [llvm-dev] [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: [hidden email]


Inactive hide details for Graham Yiu---11/02/2017 05:26:58 PM---Hello, I'd like to propose turning on the partial inliner (-ena
Graham Yiu---11/02/2017 05:26:58 PM---Hello, I'd like to propose turning on the partial inliner (-enable-partial-inlining) by default.

From: Graham Yiu/Toronto/IBM
To: [hidden email]
Cc: [hidden email], [hidden email]
Date: 11/02/2017 05:26 PM
Subject: [RFC] Enable Partial Inliner by default




Hello,

I'd like to propose turning on the partial inliner (-enable-partial-inlining) by default.

We've seen small gains on SPEC2006/2017 runtimes as well as lnt compile-times with a 2nd stage bootstrap of LLVM. We also saw positive gains on our internal workloads.

-------------------------------------
Brief description of Partial Inlining
-------------------------------------
A pass in opt that runs after the normal inlining pass. Looks for branches to a return block in the entry and immediate successor blocks of a function. If found, it outlines the rest of the function using the CodeExtractor. It then attempts to inline the leftover entry block (and possibly one or more of its successors) to all its callers. This effectively peels the early return block(s) into the caller, which could be executed without incurring the call overhead of the function just to return immediately. Inlining and call overhead cost, as well as branch probabilities of the return block(s) are taken into account before inlining is done. If inlining is not successful, then the changes are discarded.

eg.

void foo() {
bar();
// rest of the code in foo
}

void bar() {
if (X)
return;
// rest of code (to be outlined)
}

After Partial Inlining:

void foo() {
if (!X)
bar.outlined();
// rest of the code in foo
}

void bar.outlined() {
// rest of the code in bar
}


Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode

----------------------------------------------
Runtime performance (speed)
----------------------------------------------
Workload Improvement
-------- -----------
SPEC2006(C/C++) 0.06% (geomean)
SPEC2017(C/C++) 0.10% (geomean)
----------------------------------------------
Compile time performance for Bootstrapped LLVM
----------------------------------------------
Workload Improvement
-------- -----------
SPEC2006(C/C++) 0.41% (cumulative)
SPEC2017(C/C++) -0.16% (cumulative)
lnt 0.61% (geomean)
----------------------------------------------
Compile time performance
----------------------------------------------
Workload Increase
-------- --------
SPEC2006(C/C++) 1.31% (cumulative)
SPEC2017(C/C++) 0.25% (cumulative)
----------------------------------------------
Code size
----------------------------------------------
Workload Increase
-------- --------
SPEC2006(C/C++) 3.90% (geomean)
SPEC2017(C/C++) 1.05% (geomean)

NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark "astar", which increased by 86%. Removing this outlier, we get a more reasonable increase of 0.58%.

NOTE2: There is a patch up for review on Phabricator to enhance the partial inliner with the presence of profiling information (https://reviews.llvm.org/D38190).


Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]





_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev

Hi Evgeny,

Ah, yes, I guess I wasn't clear in my original email. I am proposing to enable it by default on both the new and current pass managers. However, I didn't collect any data for the current pass manager, since I'm assuming (hoping) the new pass manager will be the new default at some point in the future.

I don't think the partial inliner is enabled by default on the new pass manager (unless something changed recently). I do know it requires a slightly different option to enable (-enable-npm-partial-inlining).

Cheers,

Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]


Inactive hide details for Evgeny Astigeevich ---11/02/2017 06:19:18 PM---Hi Graham, Is your RFC to enable it with the current pEvgeny Astigeevich ---11/02/2017 06:19:18 PM---Hi Graham, Is your RFC to enable it with the current pass manager? If so, do you have benchmark data

From: Evgeny Astigeevich <[hidden email]>
To: Graham Yiu <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>
Date: 11/02/2017 06:19 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default





Hi Graham,

Is your RFC to enable it with the current pass manager? If so, do you have benchmark data for it?
Am I correct the new pass manager turns the partial inliner by default?

Thanks,
Evgeny Astigeevich

From: llvm-dev <[hidden email]> on behalf of Graham Yiu via llvm-dev <[hidden email]>
Reply-To:
Graham Yiu <[hidden email]>
Date:
Thursday, 2 November 2017 at 22:05
To:
"[hidden email]" <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>
Subject:
Re: [llvm-dev] [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: [hidden email]


Inactive hide details for Graham Yiu---11/02/2017 05:26:58 PM---Hello, I'd like to propose turning on the partial inliner (-enaGraham Yiu---11/02/2017 05:26:58 PM---Hello, I'd like to propose turning on the partial inliner (-enable-partial-inlining) by default.

From:
Graham Yiu/Toronto/IBM
To:
[hidden email]
Cc:
[hidden email], [hidden email]
Date:
11/02/2017 05:26 PM
Subject:
[RFC] Enable Partial Inliner by default





Hello,


I'd like to propose turning on the partial inliner (-enable-partial-inlining) by default.


We've seen small gains on SPEC2006/2017 runtimes as well as lnt compile-times with a 2nd stage bootstrap of LLVM. We also saw positive gains on our internal workloads.


-------------------------------------
Brief description of Partial Inlining
-------------------------------------
A pass in opt that runs after the normal inlining pass. Looks for branches to a return block in the entry and immediate successor blocks of a function. If found, it outlines the rest of the function using the CodeExtractor. It then attempts to inline the leftover entry block (and possibly one or more of its successors) to all its callers. This effectively peels the early return block(s) into the caller, which could be executed without incurring the call overhead of the function just to return immediately. Inlining and call overhead cost, as well as branch probabilities of the return block(s) are taken into account before inlining is done. If inlining is not successful, then the changes are discarded.


eg.


void foo() {
bar();
// rest of the code in foo
}


void bar() {
if (X)
return;
// rest of code (to be outlined)
}


After Partial Inlining:


void foo() {
if (!X)
bar.outlined();
// rest of the code in foo
}


void bar.outlined() {
// rest of the code in bar
}



Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode


----------------------------------------------
Runtime performance (speed)
----------------------------------------------
Workload Improvement
-------- -----------
SPEC2006(C/C++) 0.06% (geomean)
SPEC2017(C/C++) 0.10% (geomean)
----------------------------------------------
Compile time performance for Bootstrapped LLVM
----------------------------------------------
Workload Improvement
-------- -----------
SPEC2006(C/C++) 0.41% (cumulative)
SPEC2017(C/C++) -0.16% (cumulative)
lnt 0.61% (geomean)
----------------------------------------------
Compile time performance
----------------------------------------------
Workload Increase
-------- --------
SPEC2006(C/C++) 1.31% (cumulative)
SPEC2017(C/C++) 0.25% (cumulative)
----------------------------------------------
Code size
----------------------------------------------
Workload Increase
-------- --------
SPEC2006(C/C++) 3.90% (geomean)
SPEC2017(C/C++) 1.05% (geomean)


NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark "astar", which increased by 86%. Removing this outlier, we get a more reasonable increase of 0.58%.


NOTE2: There is a patch up for review on Phabricator to enhance the partial inliner with the presence of profiling information (
https://reviews.llvm.org/D38190).


Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]







_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev
Hi Graham,

I think this is a good idea. It is also useful for libquantum, where
together with some other changes, it enables Polly to perform libfusion.

The ARM people also played with the partial inliner and might have
feedback.

Best,
Tobias

On Thu, Nov 2, 2017, at 23:05, Graham Yiu via llvm-dev wrote:

>
> 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: [hidden email]
>
>
>
> From:   Graham Yiu/Toronto/IBM
> To:     [hidden email]
> Cc:     [hidden email], [hidden email]
> Date:   11/02/2017 05:26 PM
> Subject:        [RFC] Enable Partial Inliner by default
>
>
> Hello,
>
> I'd like to propose turning on the partial inliner
> (-enable-partial-inlining) by default.
>
> We've seen small gains on SPEC2006/2017 runtimes as well as lnt
> compile-times with a 2nd stage bootstrap of LLVM.  We also saw positive
> gains on our internal workloads.
>
> -------------------------------------
> Brief description of Partial Inlining
> -------------------------------------
> A pass in opt that runs after the normal inlining pass.  Looks for
> branches
> to a return block in the entry and immediate successor blocks of a
> function.  If found, it outlines the rest of the function using the
> CodeExtractor.  It then attempts to inline the leftover entry block (and
> possibly one or more of its successors) to all its callers.  This
> effectively peels the early return block(s) into the caller, which could
> be
> executed without incurring the call overhead of the function just to
> return
> immediately.  Inlining and call overhead cost, as well as branch
> probabilities of the return block(s) are taken into account before
> inlining
> is done.  If inlining is not successful, then the changes are discarded.
>
> eg.
>
> void foo() {
>   bar();
>   // rest of the code in foo
> }
>
> void bar() {
>   if (X)
>     return;
>   // rest of code (to be outlined)
> }
>
> After Partial Inlining:
>
> void foo() {
>   if (!X)
>     bar.outlined();
>   // rest of the code in foo
> }
>
> void bar.outlined() {
>   // rest of the code in bar
> }
>
>
> Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode
>
> ----------------------------------------------
> Runtime performance (speed)
> ----------------------------------------------
> Workload                Improvement
> --------                -----------
> SPEC2006(C/C++) 0.06%           (geomean)
> SPEC2017(C/C++) 0.10%           (geomean)
> ----------------------------------------------
> Compile time performance for Bootstrapped LLVM
> ----------------------------------------------
> Workload                Improvement
> --------                -----------
> SPEC2006(C/C++) 0.41%           (cumulative)
> SPEC2017(C/C++) -0.16%  (cumulative)
> lnt                     0.61%           (geomean)
> ----------------------------------------------
> Compile time performance
> ----------------------------------------------
> Workload                Increase
> --------                --------
> SPEC2006(C/C++) 1.31%           (cumulative)
> SPEC2017(C/C++) 0.25%           (cumulative)
> ----------------------------------------------
> Code size
> ----------------------------------------------
> Workload                Increase
> --------                --------
> SPEC2006(C/C++) 3.90%           (geomean)
> SPEC2017(C/C++) 1.05%           (geomean)
>
> NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark
> "astar", which increased by 86%.  Removing this outlier, we get a more
> reasonable increase of 0.58%.
>
> NOTE2: There is a patch up for review on Phabricator to enhance the
> partial
> inliner with the presence of profiling information (
> https://reviews.llvm.org/D38190).
>
>
> Graham Yiu
> LLVM Compiler Development
> IBM Toronto Software Lab
> Office: (905) 413-4077      C2-707/8200/Markham
> Email: [hidden email]
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> Email had 1 attachment:
> + graycol.gif
>   1k (image/gif)
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev
Hi

On 02/11/2017 23:31, Tobias Grosser wrote:
> Hi Graham,
>
> I think this is a good idea. It is also useful for libquantum, where
> together with some other changes, it enables Polly to perform libfusion.
>
> The ARM people also played with the partial inliner and might have
> feedback.
>

We have been using the partial inliner on a range of large benchmarks
internally for a while now. AFAIK the only problem we found was fixed
upstream in https://reviews.llvm.org/rL317084.

Compile time is not our primary concern, so I cannot really comment on
the impact there.

Cheers,
Florian
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev
Hi,

We'd like to check impact on armv7m and armv6m targets, especially code size. We have not tried the partial inliner on them.

Could a decision to turn it on by default wait for results?

Thanks,
Evgeny Astigeevich
The Arm Compiler Optimization team

-----Original Message-----
From: llvm-dev <[hidden email]> on behalf of Tobias Grosser via llvm-dev <[hidden email]>
Reply-To: Tobias Grosser <[hidden email]>
Date: Thursday, 2 November 2017 at 23:32
To: Graham Yiu <[hidden email]>, "[hidden email]" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Hi Graham,

I think this is a good idea. It is also useful for libquantum, where
together with some other changes, it enables Polly to perform libfusion.

The ARM people also played with the partial inliner and might have
feedback.

Best,
Tobias

On Thu, Nov 2, 2017, at 23:05, Graham Yiu via llvm-dev wrote:

>
> 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: [hidden email]
>
>
>
> From:   Graham Yiu/Toronto/IBM
> To:     [hidden email]
> Cc:     [hidden email], [hidden email]
> Date:   11/02/2017 05:26 PM
> Subject:        [RFC] Enable Partial Inliner by default
>
>
> Hello,
>
> I'd like to propose turning on the partial inliner
> (-enable-partial-inlining) by default.
>
> We've seen small gains on SPEC2006/2017 runtimes as well as lnt
> compile-times with a 2nd stage bootstrap of LLVM.  We also saw positive
> gains on our internal workloads.
>
> -------------------------------------
> Brief description of Partial Inlining
> -------------------------------------
> A pass in opt that runs after the normal inlining pass.  Looks for
> branches
> to a return block in the entry and immediate successor blocks of a
> function.  If found, it outlines the rest of the function using the
> CodeExtractor.  It then attempts to inline the leftover entry block (and
> possibly one or more of its successors) to all its callers.  This
> effectively peels the early return block(s) into the caller, which could
> be
> executed without incurring the call overhead of the function just to
> return
> immediately.  Inlining and call overhead cost, as well as branch
> probabilities of the return block(s) are taken into account before
> inlining
> is done.  If inlining is not successful, then the changes are discarded.
>
> eg.
>
> void foo() {
>   bar();
>   // rest of the code in foo
> }
>
> void bar() {
>   if (X)
>     return;
>   // rest of code (to be outlined)
> }
>
> After Partial Inlining:
>
> void foo() {
>   if (!X)
>     bar.outlined();
>   // rest of the code in foo
> }
>
> void bar.outlined() {
>   // rest of the code in bar
> }
>
>
> Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode
>
> ----------------------------------------------
> Runtime performance (speed)
> ----------------------------------------------
> Workload                Improvement
> --------                -----------
> SPEC2006(C/C++) 0.06%           (geomean)
> SPEC2017(C/C++) 0.10%           (geomean)
> ----------------------------------------------
> Compile time performance for Bootstrapped LLVM
> ----------------------------------------------
> Workload                Improvement
> --------                -----------
> SPEC2006(C/C++) 0.41%           (cumulative)
> SPEC2017(C/C++) -0.16%  (cumulative)
> lnt                     0.61%           (geomean)
> ----------------------------------------------
> Compile time performance
> ----------------------------------------------
> Workload                Increase
> --------                --------
> SPEC2006(C/C++) 1.31%           (cumulative)
> SPEC2017(C/C++) 0.25%           (cumulative)
> ----------------------------------------------
> Code size
> ----------------------------------------------
> Workload                Increase
> --------                --------
> SPEC2006(C/C++) 3.90%           (geomean)
> SPEC2017(C/C++) 1.05%           (geomean)
>
> NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark
> "astar", which increased by 86%.  Removing this outlier, we get a more
> reasonable increase of 0.58%.
>
> NOTE2: There is a patch up for review on Phabricator to enhance the
> partial
> inliner with the presence of profiling information (
> https://reviews.llvm.org/D38190).
>
>
> Graham Yiu
> LLVM Compiler Development
> IBM Toronto Software Lab
> Office: (905) 413-4077      C2-707/8200/Markham
> Email: [hidden email]
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> Email had 1 attachment:
> + graycol.gif
>   1k (image/gif)
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev


> On Nov 2, 2017, at 3:05 PM, Graham Yiu via llvm-dev <[hidden email]> wrote:
>
> 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: [hidden email]
>
> <graycol.gif>Graham Yiu---11/02/2017 05:26:58 PM---Hello, I'd like to propose turning on the partial inliner (-enable-partial-inlining) by default.
>
> From: Graham Yiu/Toronto/IBM
> To: [hidden email]
> Cc: [hidden email], [hidden email]
> Date: 11/02/2017 05:26 PM
> Subject: [RFC] Enable Partial Inliner by default
>
>
>
> Hello,
>
> I'd like to propose turning on the partial inliner (-enable-partial-inlining) by default.
>
> We've seen small gains on SPEC2006/2017 runtimes as well as lnt compile-times with a 2nd stage bootstrap of LLVM. We also saw positive gains on our internal workloads.
>
> -------------------------------------
> Brief description of Partial Inlining
> -------------------------------------
> A pass in opt that runs after the normal inlining pass. Looks for branches to a return block in the entry and immediate successor blocks of a function. If found, it outlines the rest of the function using the CodeExtractor.

Since you mention outlining of code: Does this negatively affect the debug info quality?

-- adrian


> It then attempts to inline the leftover entry block (and possibly one or more of its successors) to all its callers. This effectively peels the early return block(s) into the caller, which could be executed without incurring the call overhead of the function just to return immediately. Inlining and call overhead cost, as well as branch probabilities of the return block(s) are taken into account before inlining is done. If inlining is not successful, then the changes are discarded.
>
> eg.
>
> void foo() {
> bar();
> // rest of the code in foo
> }
>
> void bar() {
> if (X)
> return;
> // rest of code (to be outlined)
> }
>
> After Partial Inlining:
>
> void foo() {
> if (!X)
> bar.outlined();
> // rest of the code in foo
> }
>
> void bar.outlined() {
> // rest of the code in bar
> }
>
>
> Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode
>
> ----------------------------------------------
> Runtime performance (speed)
> ----------------------------------------------
> Workload Improvement
> -------- -----------
> SPEC2006(C/C++) 0.06% (geomean)
> SPEC2017(C/C++) 0.10% (geomean)
> ----------------------------------------------
> Compile time performance for Bootstrapped LLVM
> ----------------------------------------------
> Workload Improvement
> -------- -----------
> SPEC2006(C/C++) 0.41% (cumulative)
> SPEC2017(C/C++) -0.16% (cumulative)
> lnt 0.61% (geomean)
> ----------------------------------------------
> Compile time performance
> ----------------------------------------------
> Workload Increase
> -------- --------
> SPEC2006(C/C++) 1.31% (cumulative)
> SPEC2017(C/C++) 0.25% (cumulative)
> ----------------------------------------------
> Code size
> ----------------------------------------------
> Workload Increase
> -------- --------
> SPEC2006(C/C++) 3.90% (geomean)
> SPEC2017(C/C++) 1.05% (geomean)
>
> NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark "astar", which increased by 86%. Removing this outlier, we get a more reasonable increase of 0.58%.
>
> NOTE2: There is a patch up for review on Phabricator to enhance the partial inliner with the presence of profiling information (https://reviews.llvm.org/D38190).
>
>
> Graham Yiu
> LLVM Compiler Development
> IBM Toronto Software Lab
> Office: (905) 413-4077 C2-707/8200/Markham
> Email: [hidden email]
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev

Hi Adrian,

As far as I know, the code extractor takes care of fixing up the debug information, if necessary. However, I haven't verified this myself and to be honest my knowledge of how debug information is represented in LLVM is limited.

Cheers,

Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]


Inactive hide details for Adrian Prantl ---11/03/2017 12:21:16 PM---> On Nov 2, 2017, at 3:05 PM, Graham Yiu via llvm-dev <llvmAdrian Prantl ---11/03/2017 12:21:16 PM---> On Nov 2, 2017, at 3:05 PM, Graham Yiu via llvm-dev <[hidden email]> wrote: >

From: Adrian Prantl <[hidden email]>
To: Graham Yiu <[hidden email]>
Cc: [hidden email], [hidden email]
Date: 11/03/2017 12:21 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default
Sent by: [hidden email]







> On Nov 2, 2017, at 3:05 PM, Graham Yiu via llvm-dev <[hidden email]> wrote:
>
> 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: [hidden email]
>
> <graycol.gif>Graham Yiu---11/02/2017 05:26:58 PM---Hello, I'd like to propose turning on the partial inliner (-enable-partial-inlining) by default.
>
> From: Graham Yiu/Toronto/IBM
> To: [hidden email]
> Cc: [hidden email], [hidden email]
> Date: 11/02/2017 05:26 PM
> Subject: [RFC] Enable Partial Inliner by default
>
>
>
> Hello,
>
> I'd like to propose turning on the partial inliner (-enable-partial-inlining) by default.
>
> We've seen small gains on SPEC2006/2017 runtimes as well as lnt compile-times with a 2nd stage bootstrap of LLVM. We also saw positive gains on our internal workloads.
>
> -------------------------------------
> Brief description of Partial Inlining
> -------------------------------------
> A pass in opt that runs after the normal inlining pass. Looks for branches to a return block in the entry and immediate successor blocks of a function. If found, it outlines the rest of the function using the CodeExtractor.

Since you mention outlining of code: Does this negatively affect the debug info quality?

-- adrian


> It then attempts to inline the leftover entry block (and possibly one or more of its successors) to all its callers. This effectively peels the early return block(s) into the caller, which could be executed without incurring the call overhead of the function just to return immediately. Inlining and call overhead cost, as well as branch probabilities of the return block(s) are taken into account before inlining is done. If inlining is not successful, then the changes are discarded.
>
> eg.
>
> void foo() {
> bar();
> // rest of the code in foo
> }
>
> void bar() {
> if (X)
> return;
> // rest of code (to be outlined)
> }
>
> After Partial Inlining:
>
> void foo() {
> if (!X)
> bar.outlined();
> // rest of the code in foo
> }
>
> void bar.outlined() {
> // rest of the code in bar
> }
>
>
> Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode
>
> ----------------------------------------------
> Runtime performance (speed)
> ----------------------------------------------
> Workload Improvement
> -------- -----------
> SPEC2006(C/C++) 0.06% (geomean)
> SPEC2017(C/C++) 0.10% (geomean)
> ----------------------------------------------
> Compile time performance for Bootstrapped LLVM
> ----------------------------------------------
> Workload Improvement
> -------- -----------
> SPEC2006(C/C++) 0.41% (cumulative)
> SPEC2017(C/C++) -0.16% (cumulative)
> lnt 0.61% (geomean)
> ----------------------------------------------
> Compile time performance
> ----------------------------------------------
> Workload Increase
> -------- --------
> SPEC2006(C/C++) 1.31% (cumulative)
> SPEC2017(C/C++) 0.25% (cumulative)
> ----------------------------------------------
> Code size
> ----------------------------------------------
> Workload Increase
> -------- --------
> SPEC2006(C/C++) 3.90% (geomean)
> SPEC2017(C/C++) 1.05% (geomean)
>
> NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark "astar", which increased by 86%. Removing this outlier, we get a more reasonable increase of 0.58%.
>
> NOTE2: There is a patch up for review on Phabricator to enhance the partial inliner with the presence of profiling information (
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D38190&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=vHBrl23Udp8MJ7l9cceP-oY_G3_H42oc7IuMFbx90_Y&s=Hzu_t0oXe3-l5xEwxx6s4eBMb6oKEGsi1vxFkqGHlaI&e=).
>
>
> Graham Yiu
> LLVM Compiler Development
> IBM Toronto Software Lab
> Office: (905) 413-4077 C2-707/8200/Markham
> Email: [hidden email]
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=vHBrl23Udp8MJ7l9cceP-oY_G3_H42oc7IuMFbx90_Y&s=pjIBJMaH7s_RCLdln5Z-pyBGmlqXE43Ch0Rh6GnY9oU&e=





_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev

Hi Evgeny,

Yes, please do. It was our hope that folks would verify the impact of the partial inliner on the platforms they're currently working on.

Cheers,

Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]


Inactive hide details for Evgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and armv6m tarEvgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and armv6m targets, especially code size. We have not tried

From: Evgeny Astigeevich <[hidden email]>
To: Tobias Grosser <[hidden email]>, Graham Yiu <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>
Date: 11/03/2017 12:18 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default





Hi,



We'd like to check impact on armv7m and armv6m targets, especially code size. We have not tried the partial inliner on them.



Could a decision to turn it on by default wait for results?



Thanks,

Evgeny Astigeevich

The Arm Compiler Optimization team



-----Original Message-----

From: llvm-dev <[hidden email]> on behalf of Tobias Grosser via llvm-dev <[hidden email]>

Reply-To: Tobias Grosser <[hidden email]>

Date: Thursday, 2 November 2017 at 23:32

To: Graham Yiu <[hidden email]>, "[hidden email]" <[hidden email]>

Cc: "[hidden email]" <[hidden email]>

Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default



Hi Graham,



I think this is a good idea. It is also useful for libquantum, where

together with some other changes, it enables Polly to perform libfusion.



The ARM people also played with the partial inliner and might have

feedback.



Best,

Tobias



On Thu, Nov 2, 2017, at 23:05, Graham Yiu via llvm-dev wrote:

>

> 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: [hidden email]

>

>

>

> From:   Graham Yiu/Toronto/IBM

> To:     [hidden email]

> Cc:     [hidden email], [hidden email]

> Date:   11/02/2017 05:26 PM

> Subject:        [RFC] Enable Partial Inliner by default

>

>

> Hello,

>

> I'd like to propose turning on the partial inliner

> (-enable-partial-inlining) by default.

>

> We've seen small gains on SPEC2006/2017 runtimes as well as lnt

> compile-times with a 2nd stage bootstrap of LLVM.  We also saw positive

> gains on our internal workloads.

>

> -------------------------------------

> Brief description of Partial Inlining

> -------------------------------------

> A pass in opt that runs after the normal inlining pass.  Looks for

> branches

> to a return block in the entry and immediate successor blocks of a

> function.  If found, it outlines the rest of the function using the

> CodeExtractor.  It then attempts to inline the leftover entry block (and

> possibly one or more of its successors) to all its callers.  This

> effectively peels the early return block(s) into the caller, which could

> be

> executed without incurring the call overhead of the function just to

> return

> immediately.  Inlining and call overhead cost, as well as branch

> probabilities of the return block(s) are taken into account before

> inlining

> is done.  If inlining is not successful, then the changes are discarded.

>

> eg.

>

> void foo() {

>   bar();

>   // rest of the code in foo

> }

>

> void bar() {

>   if (X)

>     return;

>   // rest of code (to be outlined)

> }

>

> After Partial Inlining:

>

> void foo() {

>   if (!X)

>     bar.outlined();

>   // rest of the code in foo

> }

>

> void bar.outlined() {

>   // rest of the code in bar

> }

>

>

> Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode

>

> ----------------------------------------------

> Runtime performance (speed)

> ----------------------------------------------

> Workload                Improvement

> --------                -----------

> SPEC2006(C/C++) 0.06%           (geomean)

> SPEC2017(C/C++) 0.10%           (geomean)

> ----------------------------------------------

> Compile time performance for Bootstrapped LLVM

> ----------------------------------------------

> Workload                Improvement

> --------                -----------

> SPEC2006(C/C++) 0.41%           (cumulative)

> SPEC2017(C/C++) -0.16%  (cumulative)

> lnt                     0.61%           (geomean)

> ----------------------------------------------

> Compile time performance

> ----------------------------------------------

> Workload                Increase

> --------                --------

> SPEC2006(C/C++) 1.31%           (cumulative)

> SPEC2017(C/C++) 0.25%           (cumulative)

> ----------------------------------------------

> Code size

> ----------------------------------------------

> Workload                Increase

> --------                --------

> SPEC2006(C/C++) 3.90%           (geomean)

> SPEC2017(C/C++) 1.05%           (geomean)

>

> NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark

> "astar", which increased by 86%.  Removing this outlier, we get a more

> reasonable increase of 0.58%.

>

> NOTE2: There is a patch up for review on Phabricator to enhance the

> partial

> inliner with the presence of profiling information (

>
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D38190&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=6o17wydYZM0l4kPAb3l3cJ95JRPoYb-3l4sHv-R0GaA&e=).

>

>

> Graham Yiu

> LLVM Compiler Development

> IBM Toronto Software Lab

> Office: (905) 413-4077      C2-707/8200/Markham

> Email: [hidden email]

>

> _______________________________________________

> LLVM Developers mailing list

> [hidden email]

>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e=

> Email had 1 attachment:

> + graycol.gif

>   1k (image/gif)

_______________________________________________

LLVM Developers mailing list

[hidden email]

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e=










_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev


On Fri, Nov 3, 2017 at 9:21 AM, Adrian Prantl via llvm-dev <[hidden email]> wrote:


> On Nov 2, 2017, at 3:05 PM, Graham Yiu via llvm-dev <[hidden email]> wrote:
>
> 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: <a href="tel:%28905%29%20413-4077" value="+19054134077" target="_blank">(905) 413-4077 C2-707/8200/Markham
> Email: [hidden email]
>
> <graycol.gif>Graham Yiu---11/02/2017 05:26:58 PM---Hello, I'd like to propose turning on the partial inliner (-enable-partial-inlining) by default.
>
> From: Graham Yiu/Toronto/IBM
> To: [hidden email]
> Cc: [hidden email], [hidden email]
> Date: 11/02/2017 05:26 PM
> Subject: [RFC] Enable Partial Inliner by default
>
>
>
> Hello,
>
> I'd like to propose turning on the partial inliner (-enable-partial-inlining) by default.
>
> We've seen small gains on SPEC2006/2017 runtimes as well as lnt compile-times with a 2nd stage bootstrap of LLVM. We also saw positive gains on our internal workloads.
>
> -------------------------------------
> Brief description of Partial Inlining
> -------------------------------------
> A pass in opt that runs after the normal inlining pass. Looks for branches to a return block in the entry and immediate successor blocks of a function. If found, it outlines the rest of the function using the CodeExtractor.

Since you mention outlining of code: Does this negatively affect the debug info quality?

-- adrian

It's not merging anything together so line information is always preserved. For dbg.declare/dbg.addr intrinsics it depends on if the allocas are shrinkwrapped into the outlined function, otherwise the addr is replaced with "metadata !{}". I'm not entirely sure on how dbg.value looks off the top of my head. I haven't actually debugged partial-inlined code so I can't say anything about loss of context from the outlining but those are some observations from the code itself.

-- River Riddle

 


> It then attempts to inline the leftover entry block (and possibly one or more of its successors) to all its callers. This effectively peels the early return block(s) into the caller, which could be executed without incurring the call overhead of the function just to return immediately. Inlining and call overhead cost, as well as branch probabilities of the return block(s) are taken into account before inlining is done. If inlining is not successful, then the changes are discarded.
>
> eg.
>
> void foo() {
> bar();
> // rest of the code in foo
> }
>
> void bar() {
> if (X)
> return;
> // rest of code (to be outlined)
> }
>
> After Partial Inlining:
>
> void foo() {
> if (!X)
> bar.outlined();
> // rest of the code in foo
> }
>
> void bar.outlined() {
> // rest of the code in bar
> }
>
>
> Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode
>
> ----------------------------------------------
> Runtime performance (speed)
> ----------------------------------------------
> Workload Improvement
> -------- -----------
> SPEC2006(C/C++) 0.06% (geomean)
> SPEC2017(C/C++) 0.10% (geomean)
> ----------------------------------------------
> Compile time performance for Bootstrapped LLVM
> ----------------------------------------------
> Workload Improvement
> -------- -----------
> SPEC2006(C/C++) 0.41% (cumulative)
> SPEC2017(C/C++) -0.16% (cumulative)
> lnt 0.61% (geomean)
> ----------------------------------------------
> Compile time performance
> ----------------------------------------------
> Workload Increase
> -------- --------
> SPEC2006(C/C++) 1.31% (cumulative)
> SPEC2017(C/C++) 0.25% (cumulative)
> ----------------------------------------------
> Code size
> ----------------------------------------------
> Workload Increase
> -------- --------
> SPEC2006(C/C++) 3.90% (geomean)
> SPEC2017(C/C++) 1.05% (geomean)
>
> NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark "astar", which increased by 86%. Removing this outlier, we get a more reasonable increase of 0.58%.
>
> NOTE2: There is a patch up for review on Phabricator to enhance the partial inliner with the presence of profiling information (https://reviews.llvm.org/D38190).
>
>
> Graham Yiu
> LLVM Compiler Development
> IBM Toronto Software Lab
> Office: <a href="tel:%28905%29%20413-4077" value="+19054134077" target="_blank">(905) 413-4077 C2-707/8200/Markham
> Email: [hidden email]
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev
Hi Graham, thanks for driving this. I assume the multi-region partial inliner you are working on will eventually replace the current single region partial-inliner and be turned on even without PGO.   If that is the plan, is it better to wait until that work is more complete, or the multi-region support will only be used with profile feedback?

David


On Thu, Nov 2, 2017 at 2:26 PM, Graham Yiu <[hidden email]> wrote:

Hello,

I'd like to propose turning on the partial inliner (-enable-partial-inlining) by default.

We've seen small gains on SPEC2006/2017 runtimes as well as lnt compile-times with a 2nd stage bootstrap of LLVM. We also saw positive gains on our internal workloads.

-------------------------------------
Brief description of Partial Inlining
-------------------------------------
A pass in opt that runs after the normal inlining pass. Looks for branches to a return block in the entry and immediate successor blocks of a function. If found, it outlines the rest of the function using the CodeExtractor. It then attempts to inline the leftover entry block (and possibly one or more of its successors) to all its callers. This effectively peels the early return block(s) into the caller, which could be executed without incurring the call overhead of the function just to return immediately. Inlining and call overhead cost, as well as branch probabilities of the return block(s) are taken into account before inlining is done. If inlining is not successful, then the changes are discarded.

eg.

void foo() {
bar();
// rest of the code in foo
}

void bar() {
if (X)
return;
// rest of code (to be outlined)
}

After Partial Inlining:

void foo() {
if (!X)
bar.outlined();
// rest of the code in foo
}

void bar.outlined() {
// rest of the code in bar
}


Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode

----------------------------------------------
Runtime performance (speed)
----------------------------------------------
Workload Improvement
-------- -----------
SPEC2006(C/C++) 0.06% (geomean)
SPEC2017(C/C++) 0.10% (geomean)
----------------------------------------------
Compile time performance for Bootstrapped LLVM
----------------------------------------------
Workload Improvement
-------- -----------
SPEC2006(C/C++) 0.41% (cumulative)
SPEC2017(C/C++) -0.16% (cumulative)
lnt 0.61% (geomean)
----------------------------------------------
Compile time performance
----------------------------------------------
Workload Increase
-------- --------
SPEC2006(C/C++) 1.31% (cumulative)
SPEC2017(C/C++) 0.25% (cumulative)
----------------------------------------------
Code size
----------------------------------------------
Workload Increase
-------- --------
SPEC2006(C/C++) 3.90% (geomean)
SPEC2017(C/C++) 1.05% (geomean)

NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark "astar", which increased by 86%. Removing this outlier, we get a more reasonable increase of 0.58%.

NOTE2: There is a patch up for review on Phabricator to enhance the partial inliner with the presence of profiling information (https://reviews.llvm.org/D38190).


Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: <a href="tel:(905)%20413-4077" value="+19054134077" target="_blank">(905) 413-4077 C2-707/8200/Markham
Email: [hidden email]



_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev

Hi David,

I think we should support multi-region outlining with and without PGO information at some point. However, the scope of the current patch (D38190) should be with PGO information only, as we haven't come up with a viable heuristic to outline multiple regions without PGO data.

The current single region outlining (really, the 'tail' region of the function) seems to have some potential in various workloads, so I think it's worthwhile to turn it on by default to expose the optimization to various platforms and get more feedback on modifications/improvements we can add in the future.

Cheers,

Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]


Inactive hide details for Xinliang David Li ---11/03/2017 02:58:56 PM---Hi Graham, thanks for driving this. I assume the multi-Xinliang David Li ---11/03/2017 02:58:56 PM---Hi Graham, thanks for driving this. I assume the multi-region partial inliner you are working on wil

From: Xinliang David Li <[hidden email]>
To: Graham Yiu <[hidden email]>
Cc: llvm-dev <[hidden email]>, Jun Lim <[hidden email]>
Date: 11/03/2017 02:58 PM
Subject: Re: [RFC] Enable Partial Inliner by default





Hi Graham, thanks for driving this. I assume the multi-region partial inliner you are working on will eventually replace the current single region partial-inliner and be turned on even without PGO.   If that is the plan, is it better to wait until that work is more complete, or the multi-region support will only be used with profile feedback?

David


On Thu, Nov 2, 2017 at 2:26 PM, Graham Yiu <[hidden email]> wrote:
    Hello,

    I'd like to propose turning on the partial inliner (-enable-partial-inlining) by default.


    We've seen small gains on SPEC2006/2017 runtimes as well as lnt compile-times with a 2nd stage bootstrap of LLVM. We also saw positive gains on our internal workloads.


    -------------------------------------
    Brief description of Partial Inlining
    -------------------------------------
    A pass in opt that runs after the normal inlining pass. Looks for branches to a return block in the entry and immediate successor blocks of a function. If found, it outlines the rest of the function using the CodeExtractor. It then attempts to inline the leftover entry block (and possibly one or more of its successors) to all its callers. This effectively peels the early return block(s) into the caller, which could be executed without incurring the call overhead of the function just to return immediately. Inlining and call overhead cost, as well as branch probabilities of the return block(s) are taken into account before inlining is done. If inlining is not successful, then the changes are discarded.


    eg.


    void foo() {
    bar();
    // rest of the code in foo
    }


    void bar() {
    if (X)
    return;
    // rest of code (to be outlined)
    }


    After Partial Inlining:


    void foo() {
    if (!X)
    bar.outlined();
    // rest of the code in foo
    }


    void bar.outlined() {
    // rest of the code in bar
    }



    Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode


    ----------------------------------------------
    Runtime performance (speed)
    ----------------------------------------------
    Workload Improvement
    -------- -----------
    SPEC2006(C/C++) 0.06% (geomean)
    SPEC2017(C/C++) 0.10% (geomean)
    ----------------------------------------------
    Compile time performance for Bootstrapped LLVM
    ----------------------------------------------
    Workload Improvement
    -------- -----------
    SPEC2006(C/C++) 0.41% (cumulative)
    SPEC2017(C/C++) -0.16% (cumulative)
    lnt 0.61% (geomean)
    ----------------------------------------------
    Compile time performance
    ----------------------------------------------
    Workload Increase
    -------- --------
    SPEC2006(C/C++) 1.31% (cumulative)
    SPEC2017(C/C++) 0.25% (cumulative)
    ----------------------------------------------
    Code size
    ----------------------------------------------
    Workload Increase
    -------- --------
    SPEC2006(C/C++) 3.90% (geomean)
    SPEC2017(C/C++) 1.05% (geomean)


    NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark "astar", which increased by 86%. Removing this outlier, we get a more reasonable increase of 0.58%.


    NOTE2: There is a patch up for review on Phabricator to enhance the partial inliner with the presence of profiling information (
    https://reviews.llvm.org/D38190).


    Graham Yiu
    LLVM Compiler Development
    IBM Toronto Software Lab
    Office:
    <a href="tel:(905)%20413-4077" target="_blank">(905) 413-4077 C2-707/8200/Markham
    Email:
    [hidden email]



_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev

Hi Evgeny,

When you think the experiments on armv7m and armv6m targets will be complete? We're looking to turn this on sooner rather than later, if there aren't objections from folks running on other platforms.

Cheers,

Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]


Inactive hide details for Graham Yiu---11/03/2017 12:40:10 PM---Hi Evgeny, Yes, please do.  It was our hope that folks would veGraham Yiu---11/03/2017 12:40:10 PM---Hi Evgeny, Yes, please do. It was our hope that folks would verify the impact of the partial inline

From: Graham Yiu/Toronto/IBM
To: Evgeny Astigeevich <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, Tobias Grosser <[hidden email]>
Date: 11/03/2017 12:40 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default




Hi Evgeny,

Yes, please do. It was our hope that folks would verify the impact of the partial inliner on the platforms they're currently working on.

Cheers,

Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]



Inactive hide details for Evgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and armv6m tarEvgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and armv6m targets, especially code size. We have not tried

From: Evgeny Astigeevich <[hidden email]>
To: Tobias Grosser <[hidden email]>, Graham Yiu <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>
Date: 11/03/2017 12:18 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default




Hi,



We'd like to check impact on armv7m and armv6m targets, especially code size. We have not tried the partial inliner on them.



Could a decision to turn it on by default wait for results?



Thanks,

Evgeny Astigeevich

The Arm Compiler Optimization team



-----Original Message-----

From: llvm-dev <[hidden email]> on behalf of Tobias Grosser via llvm-dev <[hidden email]>

Reply-To: Tobias Grosser <[hidden email]>

Date: Thursday, 2 November 2017 at 23:32

To: Graham Yiu <[hidden email]>, "[hidden email]" <[hidden email]>

Cc: "[hidden email]" <[hidden email]>

Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default



Hi Graham,



I think this is a good idea. It is also useful for libquantum, where

together with some other changes, it enables Polly to perform libfusion.



The ARM people also played with the partial inliner and might have

feedback.



Best,

Tobias



On Thu, Nov 2, 2017, at 23:05, Graham Yiu via llvm-dev wrote:

>

> 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: [hidden email]

>

>

>

> From:   Graham Yiu/Toronto/IBM

> To:     [hidden email]

> Cc:     [hidden email], [hidden email]

> Date:   11/02/2017 05:26 PM

> Subject:        [RFC] Enable Partial Inliner by default

>

>

> Hello,

>

> I'd like to propose turning on the partial inliner

> (-enable-partial-inlining) by default.

>

> We've seen small gains on SPEC2006/2017 runtimes as well as lnt

> compile-times with a 2nd stage bootstrap of LLVM.  We also saw positive

> gains on our internal workloads.

>

> -------------------------------------

> Brief description of Partial Inlining

> -------------------------------------

> A pass in opt that runs after the normal inlining pass.  Looks for

> branches

> to a return block in the entry and immediate successor blocks of a

> function.  If found, it outlines the rest of the function using the

> CodeExtractor.  It then attempts to inline the leftover entry block (and

> possibly one or more of its successors) to all its callers.  This

> effectively peels the early return block(s) into the caller, which could

> be

> executed without incurring the call overhead of the function just to

> return

> immediately.  Inlining and call overhead cost, as well as branch

> probabilities of the return block(s) are taken into account before

> inlining

> is done.  If inlining is not successful, then the changes are discarded.

>

> eg.

>

> void foo() {

>   bar();

>   // rest of the code in foo

> }

>

> void bar() {

>   if (X)

>     return;

>   // rest of code (to be outlined)

> }

>

> After Partial Inlining:

>

> void foo() {

>   if (!X)

>     bar.outlined();

>   // rest of the code in foo

> }

>

> void bar.outlined() {

>   // rest of the code in bar

> }

>

>

> Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode

>

> ----------------------------------------------

> Runtime performance (speed)

> ----------------------------------------------

> Workload                Improvement

> --------                -----------

> SPEC2006(C/C++) 0.06%           (geomean)

> SPEC2017(C/C++) 0.10%           (geomean)

> ----------------------------------------------

> Compile time performance for Bootstrapped LLVM

> ----------------------------------------------

> Workload                Improvement

> --------                -----------

> SPEC2006(C/C++) 0.41%           (cumulative)

> SPEC2017(C/C++) -0.16%  (cumulative)

> lnt                     0.61%           (geomean)

> ----------------------------------------------

> Compile time performance

> ----------------------------------------------

> Workload                Increase

> --------                --------

> SPEC2006(C/C++) 1.31%           (cumulative)

> SPEC2017(C/C++) 0.25%           (cumulative)

> ----------------------------------------------

> Code size

> ----------------------------------------------

> Workload                Increase

> --------                --------

> SPEC2006(C/C++) 3.90%           (geomean)

> SPEC2017(C/C++) 1.05%           (geomean)

>

> NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark

> "astar", which increased by 86%.  Removing this outlier, we get a more

> reasonable increase of 0.58%.

>

> NOTE2: There is a patch up for review on Phabricator to enhance the

> partial

> inliner with the presence of profiling information (

>
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D38190&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=6o17wydYZM0l4kPAb3l3cJ95JRPoYb-3l4sHv-R0GaA&e=).

>

>

> Graham Yiu

> LLVM Compiler Development

> IBM Toronto Software Lab

> Office: (905) 413-4077      C2-707/8200/Markham

> Email: [hidden email]

>

> _______________________________________________

> LLVM Developers mailing list

> [hidden email]

>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e=

> Email had 1 attachment:

> + graycol.gif

>   1k (image/gif)

_______________________________________________

LLVM Developers mailing list

[hidden email]

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e=











_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev

Hi Graham,

 

I need two-three days to complete runs and compare results. As the runs are on bare-metal boards benchmarking takes more time than on hardware with OS.

 

Thanks,

Evgeny

 

From: Graham Yiu <[hidden email]>
Date: Tuesday, 7 November 2017 at 16:19
To: Evgeny Astigeevich <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, Tobias Grosser <[hidden email]>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

 

Hi Evgeny,

When you think the experiments on armv7m and armv6m targets will be complete? We're looking to turn this on sooner rather than later, if there aren't objections from folks running on other platforms.

Cheers,

Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]


Inactive hide details for Graham Yiu---11/03/2017 12:40:10 PM---Hi Evgeny, Yes, please do.  It was our hope that folks would ve
Graham Yiu---11/03/2017 12:40:10 PM---Hi Evgeny, Yes, please do. It was our hope that folks would verify the impact of the partial inline

From: Graham Yiu/Toronto/IBM
To: Evgeny Astigeevich <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, Tobias Grosser <[hidden email]>
Date: 11/03/2017 12:40 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default




Hi Evgeny,

Yes, please do. It was our hope that folks would verify the impact of the partial inliner on the platforms they're currently working on.

Cheers,

Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]



Inactive hide details for Evgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and armv6m tar
Evgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and armv6m targets, especially code size. We have not tried

From: Evgeny Astigeevich <[hidden email]>
To: Tobias Grosser <[hidden email]>, Graham Yiu <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>
Date: 11/03/2017 12:18 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default





Hi,



We'd like to check impact on armv7m and armv6m targets, especially code size. We have not tried the partial inliner on them.



Could a decision to turn it on by default wait for results?



Thanks,

Evgeny Astigeevich

The Arm Compiler Optimization team



-----Original Message-----

From: llvm-dev <[hidden email]> on behalf of Tobias Grosser via llvm-dev <[hidden email]>

Reply-To: Tobias Grosser <[hidden email]>

Date: Thursday, 2 November 2017 at 23:32

To: Graham Yiu <[hidden email]>, "[hidden email]" <[hidden email]>

Cc: "[hidden email]" <[hidden email]>

Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default



Hi Graham,



I think this is a good idea. It is also useful for libquantum, where

together with some other changes, it enables Polly to perform libfusion.



The ARM people also played with the partial inliner and might have

feedback.



Best,

Tobias



On Thu, Nov 2, 2017, at 23:05, Graham Yiu via llvm-dev wrote:

>

> 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: [hidden email]

>

>

>

> From:   Graham Yiu/Toronto/IBM

> To:     [hidden email]

> Cc:     [hidden email], [hidden email]

> Date:   11/02/2017 05:26 PM

> Subject:        [RFC] Enable Partial Inliner by default

>

>

> Hello,

>

> I'd like to propose turning on the partial inliner

> (-enable-partial-inlining) by default.

>

> We've seen small gains on SPEC2006/2017 runtimes as well as lnt

> compile-times with a 2nd stage bootstrap of LLVM.  We also saw positive

> gains on our internal workloads.

>

> -------------------------------------

> Brief description of Partial Inlining

> -------------------------------------

> A pass in opt that runs after the normal inlining pass.  Looks for

> branches

> to a return block in the entry and immediate successor blocks of a

> function.  If found, it outlines the rest of the function using the

> CodeExtractor.  It then attempts to inline the leftover entry block (and

> possibly one or more of its successors) to all its callers.  This

> effectively peels the early return block(s) into the caller, which could

> be

> executed without incurring the call overhead of the function just to

> return

> immediately.  Inlining and call overhead cost, as well as branch

> probabilities of the return block(s) are taken into account before

> inlining

> is done.  If inlining is not successful, then the changes are discarded.

>

> eg.

>

> void foo() {

>   bar();

>   // rest of the code in foo

> }

>

> void bar() {

>   if (X)

>     return;

>   // rest of code (to be outlined)

> }

>

> After Partial Inlining:

>

> void foo() {

>   if (!X)

>     bar.outlined();

>   // rest of the code in foo

> }

>

> void bar.outlined() {

>   // rest of the code in bar

> }

>

>

> Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode

>

> ----------------------------------------------

> Runtime performance (speed)

> ----------------------------------------------

> Workload                Improvement

> --------                -----------

> SPEC2006(C/C++) 0.06%           (geomean)

> SPEC2017(C/C++) 0.10%           (geomean)

> ----------------------------------------------

> Compile time performance for Bootstrapped LLVM

> ----------------------------------------------

> Workload                Improvement

> --------                -----------

> SPEC2006(C/C++) 0.41%           (cumulative)

> SPEC2017(C/C++) -0.16%  (cumulative)

> lnt                     0.61%           (geomean)

> ----------------------------------------------

> Compile time performance

> ----------------------------------------------

> Workload                Increase

> --------                --------

> SPEC2006(C/C++) 1.31%           (cumulative)

> SPEC2017(C/C++) 0.25%           (cumulative)

> ----------------------------------------------

> Code size

> ----------------------------------------------

> Workload                Increase

> --------                --------

> SPEC2006(C/C++) 3.90%           (geomean)

> SPEC2017(C/C++) 1.05%           (geomean)

>

> NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark

> "astar", which increased by 86%.  Removing this outlier, we get a more

> reasonable increase of 0.58%.

>

> NOTE2: There is a patch up for review on Phabricator to enhance the

> partial

> inliner with the presence of profiling information (

>
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D38190&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=6o17wydYZM0l4kPAb3l3cJ95JRPoYb-3l4sHv-R0GaA&e=).

>

>

> Graham Yiu

> LLVM Compiler Development

> IBM Toronto Software Lab

> Office: (905) 413-4077      C2-707/8200/Markham

> Email: [hidden email]

>

> _______________________________________________

> LLVM Developers mailing list

> [hidden email]

>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e=

> Email had 1 attachment:

> + graycol.gif

>   1k (image/gif)

_______________________________________________

LLVM Developers mailing list

[hidden email]

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e=












_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev

Hi Graham,

 

I’ve almost finished my runs. However I’ve got couple compiler crashes:

 

!dbg attachment points at wrong subprogram for function

LLVM ERROR: Broken module found, compilation aborted!

 

This will take some time to investigate.

 

Thanks,

Evgeny Astigeevich

 

 

From: Graham Yiu <[hidden email]>
Date: Tuesday, 7 November 2017 at 16:19
To: Evgeny Astigeevich <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, Tobias Grosser <[hidden email]>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

 

Hi Evgeny,

When you think the experiments on armv7m and armv6m targets will be complete? We're looking to turn this on sooner rather than later, if there aren't objections from folks running on other platforms.

Cheers,

Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]


Inactive hide details for Graham Yiu---11/03/2017 12:40:10 PM---Hi Evgeny, Yes, please do.  It was our hope that folks would ve
Graham Yiu---11/03/2017 12:40:10 PM---Hi Evgeny, Yes, please do. It was our hope that folks would verify the impact of the partial inline

From: Graham Yiu/Toronto/IBM
To: Evgeny Astigeevich <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, Tobias Grosser <[hidden email]>
Date: 11/03/2017 12:40 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default




Hi Evgeny,

Yes, please do. It was our hope that folks would verify the impact of the partial inliner on the platforms they're currently working on.

Cheers,

Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]



Inactive hide details for Evgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and armv6m tar
Evgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and armv6m targets, especially code size. We have not tried

From: Evgeny Astigeevich <[hidden email]>
To: Tobias Grosser <[hidden email]>, Graham Yiu <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>
Date: 11/03/2017 12:18 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default





Hi,



We'd like to check impact on armv7m and armv6m targets, especially code size. We have not tried the partial inliner on them.



Could a decision to turn it on by default wait for results?



Thanks,

Evgeny Astigeevich

The Arm Compiler Optimization team



-----Original Message-----

From: llvm-dev <[hidden email]> on behalf of Tobias Grosser via llvm-dev <[hidden email]>

Reply-To: Tobias Grosser <[hidden email]>

Date: Thursday, 2 November 2017 at 23:32

To: Graham Yiu <[hidden email]>, "[hidden email]" <[hidden email]>

Cc: "[hidden email]" <[hidden email]>

Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default



Hi Graham,



I think this is a good idea. It is also useful for libquantum, where

together with some other changes, it enables Polly to perform libfusion.



The ARM people also played with the partial inliner and might have

feedback.



Best,

Tobias



On Thu, Nov 2, 2017, at 23:05, Graham Yiu via llvm-dev wrote:

>

> 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: [hidden email]

>

>

>

> From:   Graham Yiu/Toronto/IBM

> To:     [hidden email]

> Cc:     [hidden email], [hidden email]

> Date:   11/02/2017 05:26 PM

> Subject:        [RFC] Enable Partial Inliner by default

>

>

> Hello,

>

> I'd like to propose turning on the partial inliner

> (-enable-partial-inlining) by default.

>

> We've seen small gains on SPEC2006/2017 runtimes as well as lnt

> compile-times with a 2nd stage bootstrap of LLVM.  We also saw positive

> gains on our internal workloads.

>

> -------------------------------------

> Brief description of Partial Inlining

> -------------------------------------

> A pass in opt that runs after the normal inlining pass.  Looks for

> branches

> to a return block in the entry and immediate successor blocks of a

> function.  If found, it outlines the rest of the function using the

> CodeExtractor.  It then attempts to inline the leftover entry block (and

> possibly one or more of its successors) to all its callers.  This

> effectively peels the early return block(s) into the caller, which could

> be

> executed without incurring the call overhead of the function just to

> return

> immediately.  Inlining and call overhead cost, as well as branch

> probabilities of the return block(s) are taken into account before

> inlining

> is done.  If inlining is not successful, then the changes are discarded.

>

> eg.

>

> void foo() {

>   bar();

>   // rest of the code in foo

> }

>

> void bar() {

>   if (X)

>     return;

>   // rest of code (to be outlined)

> }

>

> After Partial Inlining:

>

> void foo() {

>   if (!X)

>     bar.outlined();

>   // rest of the code in foo

> }

>

> void bar.outlined() {

>   // rest of the code in bar

> }

>

>

> Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode

>

> ----------------------------------------------

> Runtime performance (speed)

> ----------------------------------------------

> Workload                Improvement

> --------                -----------

> SPEC2006(C/C++) 0.06%           (geomean)

> SPEC2017(C/C++) 0.10%           (geomean)

> ----------------------------------------------

> Compile time performance for Bootstrapped LLVM

> ----------------------------------------------

> Workload                Improvement

> --------                -----------

> SPEC2006(C/C++) 0.41%           (cumulative)

> SPEC2017(C/C++) -0.16%  (cumulative)

> lnt                     0.61%           (geomean)

> ----------------------------------------------

> Compile time performance

> ----------------------------------------------

> Workload                Increase

> --------                --------

> SPEC2006(C/C++) 1.31%           (cumulative)

> SPEC2017(C/C++) 0.25%           (cumulative)

> ----------------------------------------------

> Code size

> ----------------------------------------------

> Workload                Increase

> --------                --------

> SPEC2006(C/C++) 3.90%           (geomean)

> SPEC2017(C/C++) 1.05%           (geomean)

>

> NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark

> "astar", which increased by 86%.  Removing this outlier, we get a more

> reasonable increase of 0.58%.

>

> NOTE2: There is a patch up for review on Phabricator to enhance the

> partial

> inliner with the presence of profiling information (

>
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D38190&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=6o17wydYZM0l4kPAb3l3cJ95JRPoYb-3l4sHv-R0GaA&e=).

>

>

> Graham Yiu

> LLVM Compiler Development

> IBM Toronto Software Lab

> Office: (905) 413-4077      C2-707/8200/Markham

> Email: [hidden email]

>

> _______________________________________________

> LLVM Developers mailing list

> [hidden email]

>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e=

> Email had 1 attachment:

> + graycol.gif

>   1k (image/gif)

_______________________________________________

LLVM Developers mailing list

[hidden email]

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e=












_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev

Thanks, Evgeny.

Let me know if there's something in the partial inlining code that is causing the issue(s) you're seeing.

Cheers,

Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]


Inactive hide details for Evgeny Astigeevich ---11/08/2017 05:13:09 PM---Hi Graham, I’ve almost finished my runs. However I’vEvgeny Astigeevich ---11/08/2017 05:13:09 PM---Hi Graham, I’ve almost finished my runs. However I’ve got couple compiler crashes:

From: Evgeny Astigeevich <[hidden email]>
To: Graham Yiu <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, "Tobias Grosser" <[hidden email]>, nd <[hidden email]>
Date: 11/08/2017 05:13 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default





Hi Graham,

I’ve almost finished my runs. However I’ve got couple compiler crashes:

!dbg attachment points at wrong subprogram for function

LLVM ERROR: Broken module found, compilation aborted!

This will take some time to investigate.

Thanks,
Evgeny Astigeevich


From: Graham Yiu <[hidden email]>
Date:
Tuesday, 7 November 2017 at 16:19
To:
Evgeny Astigeevich <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, Tobias Grosser <[hidden email]>
Subject:
Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Hi Evgeny,

When you think the experiments on armv7m and armv6m targets will be complete? We're looking to turn this on sooner rather than later, if there aren't objections from folks running on other platforms.


Cheers,


Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]


Inactive hide details for Graham Yiu---11/03/2017 12:40:10 PM---Hi Evgeny, Yes, please do.  It was our hope that folks would veGraham Yiu---11/03/2017 12:40:10 PM---Hi Evgeny, Yes, please do. It was our hope that folks would verify the impact of the partial inline

From:
Graham Yiu/Toronto/IBM
To:
Evgeny Astigeevich <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, Tobias Grosser <[hidden email]>
Date:
11/03/2017 12:40 PM
Subject:
Re: [llvm-dev] [RFC] Enable Partial Inliner by default





Hi Evgeny,


Yes, please do. It was our hope that folks would verify the impact of the partial inliner on the platforms they're currently working on.


Cheers,


Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]



Inactive hide details for Evgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and armv6m tarEvgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and armv6m targets, especially code size. We have not tried

From:
Evgeny Astigeevich <[hidden email]>
To:
Tobias Grosser <[hidden email]>, Graham Yiu <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>
Date:
11/03/2017 12:18 PM
Subject:
Re: [llvm-dev] [RFC] Enable Partial Inliner by default





Hi,



We'd like to check impact on armv7m and armv6m targets, especially code size. We have not tried the partial inliner on them.



Could a decision to turn it on by default wait for results?



Thanks,

Evgeny Astigeevich

The Arm Compiler Optimization team



-----Original Message-----

From: llvm-dev <[hidden email]> on behalf of Tobias Grosser via llvm-dev <[hidden email]>

Reply-To: Tobias Grosser <[hidden email]>

Date: Thursday, 2 November 2017 at 23:32

To: Graham Yiu <[hidden email]>, "[hidden email]" <[hidden email]>

Cc: "[hidden email]" <[hidden email]>

Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default



Hi Graham,



I think this is a good idea. It is also useful for libquantum, where

together with some other changes, it enables Polly to perform libfusion.



The ARM people also played with the partial inliner and might have

feedback.



Best,

Tobias



On Thu, Nov 2, 2017, at 23:05, Graham Yiu via llvm-dev wrote:

>

> 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: [hidden email]

>

>

>

> From: Graham Yiu/Toronto/IBM

> To: [hidden email]

> Cc: [hidden email], [hidden email]

> Date: 11/02/2017 05:26 PM

> Subject: [RFC] Enable Partial Inliner by default

>

>

> Hello,

>

> I'd like to propose turning on the partial inliner

> (-enable-partial-inlining) by default.

>

> We've seen small gains on SPEC2006/2017 runtimes as well as lnt

> compile-times with a 2nd stage bootstrap of LLVM. We also saw positive

> gains on our internal workloads.

>

> -------------------------------------

> Brief description of Partial Inlining

> -------------------------------------

> A pass in opt that runs after the normal inlining pass. Looks for

> branches

> to a return block in the entry and immediate successor blocks of a

> function. If found, it outlines the rest of the function using the

> CodeExtractor. It then attempts to inline the leftover entry block (and

> possibly one or more of its successors) to all its callers. This

> effectively peels the early return block(s) into the caller, which could

> be

> executed without incurring the call overhead of the function just to

> return

> immediately. Inlining and call overhead cost, as well as branch

> probabilities of the return block(s) are taken into account before

> inlining

> is done. If inlining is not successful, then the changes are discarded.

>

> eg.

>

> void foo() {

> bar();

> // rest of the code in foo

> }

>

> void bar() {

> if (X)

> return;

> // rest of code (to be outlined)

> }

>

> After Partial Inlining:

>

> void foo() {

> if (!X)

> bar.outlined();

> // rest of the code in foo

> }

>

> void bar.outlined() {

> // rest of the code in bar

> }

>

>

> Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode

>

> ----------------------------------------------

> Runtime performance (speed)

> ----------------------------------------------

> Workload Improvement

> -------- -----------

> SPEC2006(C/C++) 0.06% (geomean)

> SPEC2017(C/C++) 0.10% (geomean)

> ----------------------------------------------

> Compile time performance for Bootstrapped LLVM

> ----------------------------------------------

> Workload Improvement

> -------- -----------

> SPEC2006(C/C++) 0.41% (cumulative)

> SPEC2017(C/C++) -0.16% (cumulative)

> lnt 0.61% (geomean)

> ----------------------------------------------

> Compile time performance

> ----------------------------------------------

> Workload Increase

> -------- --------

> SPEC2006(C/C++) 1.31% (cumulative)

> SPEC2017(C/C++) 0.25% (cumulative)

> ----------------------------------------------

> Code size

> ----------------------------------------------

> Workload Increase

> -------- --------

> SPEC2006(C/C++) 3.90% (geomean)

> SPEC2017(C/C++) 1.05% (geomean)

>

> NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark

> "astar", which increased by 86%. Removing this outlier, we get a more

> reasonable increase of 0.58%.

>

> NOTE2: There is a patch up for review on Phabricator to enhance the

> partial

> inliner with the presence of profiling information (

>
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D38190&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=6o17wydYZM0l4kPAb3l3cJ95JRPoYb-3l4sHv-R0GaA&e=).

>

>

> Graham Yiu

> LLVM Compiler Development

> IBM Toronto Software Lab

> Office: (905) 413-4077 C2-707/8200/Markham

> Email: [hidden email]

>

> _______________________________________________

> LLVM Developers mailing list

> [hidden email]

>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e=

> Email had 1 attachment:

> + graycol.gif

> 1k (image/gif)

_______________________________________________

LLVM Developers mailing list

[hidden email]

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e=














_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev

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: [hidden email]


Inactive hide details for Graham Yiu---11/08/2017 06:00:05 PM---Thanks, Evgeny. Let me know if there's something in the partialGraham Yiu---11/08/2017 06:00:05 PM---Thanks, Evgeny. Let me know if there's something in the partial inlining code that is causing the is

From: Graham Yiu/Toronto/IBM
To: Evgeny Astigeevich <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, "Tobias Grosser" <[hidden email]>
Date: 11/08/2017 06:00 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default




Thanks, Evgeny.

Let me know if there's something in the partial inlining code that is causing the issue(s) you're seeing.

Cheers,

Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]



Inactive hide details for Evgeny Astigeevich ---11/08/2017 05:13:09 PM---Hi Graham, I’ve almost finished my runs. However I’vEvgeny Astigeevich ---11/08/2017 05:13:09 PM---Hi Graham, I’ve almost finished my runs. However I’ve got couple compiler crashes:

From: Evgeny Astigeevich <[hidden email]>
To: Graham Yiu <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, "Tobias Grosser" <[hidden email]>, nd <[hidden email]>
Date: 11/08/2017 05:13 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default




Hi Graham,

I’ve almost finished my runs. However I’ve got couple compiler crashes:

!dbg attachment points at wrong subprogram for function

LLVM ERROR: Broken module found, compilation aborted!

This will take some time to investigate.

Thanks,
Evgeny Astigeevich


From: Graham Yiu <[hidden email]>
Date:
Tuesday, 7 November 2017 at 16:19
To:
Evgeny Astigeevich <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, Tobias Grosser <[hidden email]>
Subject:
Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Hi Evgeny,

When you think the experiments on armv7m and armv6m targets will be complete? We're looking to turn this on sooner rather than later, if there aren't objections from folks running on other platforms.


Cheers,


Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]


Inactive hide details for Graham Yiu---11/03/2017 12:40:10 PM---Hi Evgeny, Yes, please do.  It was our hope that folks would veGraham Yiu---11/03/2017 12:40:10 PM---Hi Evgeny, Yes, please do. It was our hope that folks would verify the impact of the partial inline

From:
Graham Yiu/Toronto/IBM
To:
Evgeny Astigeevich <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, Tobias Grosser <[hidden email]>
Date:
11/03/2017 12:40 PM
Subject:
Re: [llvm-dev] [RFC] Enable Partial Inliner by default





Hi Evgeny,


Yes, please do. It was our hope that folks would verify the impact of the partial inliner on the platforms they're currently working on.


Cheers,


Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]



Inactive hide details for Evgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and armv6m tarEvgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and armv6m targets, especially code size. We have not tried

From:
Evgeny Astigeevich <[hidden email]>
To:
Tobias Grosser <[hidden email]>, Graham Yiu <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>
Date:
11/03/2017 12:18 PM
Subject:
Re: [llvm-dev] [RFC] Enable Partial Inliner by default





Hi,



We'd like to check impact on armv7m and armv6m targets, especially code size. We have not tried the partial inliner on them.



Could a decision to turn it on by default wait for results?



Thanks,

Evgeny Astigeevich

The Arm Compiler Optimization team



-----Original Message-----

From: llvm-dev <[hidden email]> on behalf of Tobias Grosser via llvm-dev <[hidden email]>

Reply-To: Tobias Grosser <[hidden email]>

Date: Thursday, 2 November 2017 at 23:32

To: Graham Yiu <[hidden email]>, "[hidden email]" <[hidden email]>

Cc: "[hidden email]" <[hidden email]>

Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default



Hi Graham,



I think this is a good idea. It is also useful for libquantum, where

together with some other changes, it enables Polly to perform libfusion.



The ARM people also played with the partial inliner and might have

feedback.



Best,

Tobias



On Thu, Nov 2, 2017, at 23:05, Graham Yiu via llvm-dev wrote:

>

> 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: [hidden email]

>

>

>

> From: Graham Yiu/Toronto/IBM

> To: [hidden email]

> Cc: [hidden email], [hidden email]

> Date: 11/02/2017 05:26 PM

> Subject: [RFC] Enable Partial Inliner by default

>

>

> Hello,

>

> I'd like to propose turning on the partial inliner

> (-enable-partial-inlining) by default.

>

> We've seen small gains on SPEC2006/2017 runtimes as well as lnt

> compile-times with a 2nd stage bootstrap of LLVM. We also saw positive

> gains on our internal workloads.

>

> -------------------------------------

> Brief description of Partial Inlining

> -------------------------------------

> A pass in opt that runs after the normal inlining pass. Looks for

> branches

> to a return block in the entry and immediate successor blocks of a

> function. If found, it outlines the rest of the function using the

> CodeExtractor. It then attempts to inline the leftover entry block (and

> possibly one or more of its successors) to all its callers. This

> effectively peels the early return block(s) into the caller, which could

> be

> executed without incurring the call overhead of the function just to

> return

> immediately. Inlining and call overhead cost, as well as branch

> probabilities of the return block(s) are taken into account before

> inlining

> is done. If inlining is not successful, then the changes are discarded.

>

> eg.

>

> void foo() {

> bar();

> // rest of the code in foo

> }

>

> void bar() {

> if (X)

> return;

> // rest of code (to be outlined)

> }

>

> After Partial Inlining:

>

> void foo() {

> if (!X)

> bar.outlined();

> // rest of the code in foo

> }

>

> void bar.outlined() {

> // rest of the code in bar

> }

>

>

> Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode

>

> ----------------------------------------------

> Runtime performance (speed)

> ----------------------------------------------

> Workload Improvement

> -------- -----------

> SPEC2006(C/C++) 0.06% (geomean)

> SPEC2017(C/C++) 0.10% (geomean)

> ----------------------------------------------

> Compile time performance for Bootstrapped LLVM

> ----------------------------------------------

> Workload Improvement

> -------- -----------

> SPEC2006(C/C++) 0.41% (cumulative)

> SPEC2017(C/C++) -0.16% (cumulative)

> lnt 0.61% (geomean)

> ----------------------------------------------

> Compile time performance

> ----------------------------------------------

> Workload Increase

> -------- --------

> SPEC2006(C/C++) 1.31% (cumulative)

> SPEC2017(C/C++) 0.25% (cumulative)

> ----------------------------------------------

> Code size

> ----------------------------------------------

> Workload Increase

> -------- --------

> SPEC2006(C/C++) 3.90% (geomean)

> SPEC2017(C/C++) 1.05% (geomean)

>

> NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark

> "astar", which increased by 86%. Removing this outlier, we get a more

> reasonable increase of 0.58%.

>

> NOTE2: There is a patch up for review on Phabricator to enhance the

> partial

> inliner with the presence of profiling information (

>
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D38190&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=6o17wydYZM0l4kPAb3l3cJ95JRPoYb-3l4sHv-R0GaA&e=).

>

>

> Graham Yiu

> LLVM Compiler Development

> IBM Toronto Software Lab

> Office: (905) 413-4077 C2-707/8200/Markham

> Email: [hidden email]

>

> _______________________________________________

> LLVM Developers mailing list

> [hidden email]

>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e=

> Email had 1 attachment:

> + graycol.gif

> 1k (image/gif)

_______________________________________________

LLVM Developers mailing list

[hidden email]

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e=















_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev

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 <[hidden email]>
Date: Friday, 10 November 2017 at 16:09
To: Evgeny Astigeevich <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, Tobias Grosser <[hidden email]>
Subject: Re: [llvm-dev] [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: [hidden email]


Inactive hide details for Graham Yiu---11/08/2017 06:00:05 PM---Thanks, Evgeny. Let me know if there's something in the partialGraham Yiu---11/08/2017 06:00:05 PM---Thanks, Evgeny. Let me know if there's something in the partial inlining code that is causing the is

From: Graham Yiu/Toronto/IBM
To: Evgeny Astigeevich <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, "Tobias Grosser" <[hidden email]>
Date: 11/08/2017 06:00 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default




Thanks, Evgeny.

Let me know if there's something in the partial inlining code that is causing the issue(s) you're seeing.

Cheers,

Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]



Inactive hide details for Evgeny Astigeevich ---11/08/2017 05:13:09 PM---Hi Graham, I’ve almost finished my runs. However I’vEvgeny Astigeevich ---11/08/2017 05:13:09 PM---Hi Graham, I’ve almost finished my runs. However I’ve got couple compiler crashes:

From: Evgeny Astigeevich <[hidden email]>
To: Graham Yiu <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, "Tobias Grosser" <[hidden email]>, nd <[hidden email]>
Date: 11/08/2017 05:13 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default





Hi Graham,

I’ve almost finished my runs. However I’ve got couple compiler crashes:

!dbg attachment points at wrong subprogram for function

LLVM ERROR: Broken module found, compilation aborted!

This will take some time to investigate.

Thanks,
Evgeny Astigeevich


From: Graham Yiu <[hidden email]>
Date:
Tuesday, 7 November 2017 at 16:19
To:
Evgeny Astigeevich <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, Tobias Grosser <[hidden email]>
Subject:
Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Hi Evgeny,

When you think the experiments on armv7m and armv6m targets will be complete? We're looking to turn this on sooner rather than later, if there aren't objections from folks running on other platforms.


Cheers,


Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]


Inactive hide details for Graham Yiu---11/03/2017 12:40:10 PM---Hi Evgeny, Yes, please do.  It was our hope that folks would ve
Graham Yiu---11/03/2017 12:40:10 PM---Hi Evgeny, Yes, please do. It was our hope that folks would verify the impact of the partial inline

From:
Graham Yiu/Toronto/IBM
To:
Evgeny Astigeevich <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, Tobias Grosser <[hidden email]>
Date:
11/03/2017 12:40 PM
Subject:
Re: [llvm-dev] [RFC] Enable Partial Inliner by default





Hi Evgeny,


Yes, please do. It was our hope that folks would verify the impact of the partial inliner on the platforms they're currently working on.


Cheers,


Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]



Inactive hide details for Evgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and armv6m tar
Evgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and armv6m targets, especially code size. We have not tried

From:
Evgeny Astigeevich <[hidden email]>
To:
Tobias Grosser <[hidden email]>, Graham Yiu <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>
Date:
11/03/2017 12:18 PM
Subject:
Re: [llvm-dev] [RFC] Enable Partial Inliner by default






Hi,



We'd like to check impact on armv7m and armv6m targets, especially code size. We have not tried the partial inliner on them.



Could a decision to turn it on by default wait for results?



Thanks,

Evgeny Astigeevich

The Arm Compiler Optimization team



-----Original Message-----

From: llvm-dev <[hidden email]> on behalf of Tobias Grosser via llvm-dev <[hidden email]>

Reply-To: Tobias Grosser <[hidden email]>

Date: Thursday, 2 November 2017 at 23:32

To: Graham Yiu <[hidden email]>, "[hidden email]" <[hidden email]>

Cc: "[hidden email]" <[hidden email]>

Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default



Hi Graham,



I think this is a good idea. It is also useful for libquantum, where

together with some other changes, it enables Polly to perform libfusion.



The ARM people also played with the partial inliner and might have

feedback.



Best,

Tobias



On Thu, Nov 2, 2017, at 23:05, Graham Yiu via llvm-dev wrote:

>

> 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: [hidden email]

>

>

>

> From: Graham Yiu/Toronto/IBM

> To: [hidden email]

> Cc: [hidden email], [hidden email]

> Date: 11/02/2017 05:26 PM

> Subject: [RFC] Enable Partial Inliner by default

>

>

> Hello,

>

> I'd like to propose turning on the partial inliner

> (-enable-partial-inlining) by default.

>

> We've seen small gains on SPEC2006/2017 runtimes as well as lnt

> compile-times with a 2nd stage bootstrap of LLVM. We also saw positive

> gains on our internal workloads.

>

> -------------------------------------

> Brief description of Partial Inlining

> -------------------------------------

> A pass in opt that runs after the normal inlining pass. Looks for

> branches

> to a return block in the entry and immediate successor blocks of a

> function. If found, it outlines the rest of the function using the

> CodeExtractor. It then attempts to inline the leftover entry block (and

> possibly one or more of its successors) to all its callers. This

> effectively peels the early return block(s) into the caller, which could

> be

> executed without incurring the call overhead of the function just to

> return

> immediately. Inlining and call overhead cost, as well as branch

> probabilities of the return block(s) are taken into account before

> inlining

> is done. If inlining is not successful, then the changes are discarded.

>

> eg.

>

> void foo() {

> bar();

> // rest of the code in foo

> }

>

> void bar() {

> if (X)

> return;

> // rest of code (to be outlined)

> }

>

> After Partial Inlining:

>

> void foo() {

> if (!X)

> bar.outlined();

> // rest of the code in foo

> }

>

> void bar.outlined() {

> // rest of the code in bar

> }

>

>

> Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode

>

> ----------------------------------------------

> Runtime performance (speed)

> ----------------------------------------------

> Workload Improvement

> -------- -----------

> SPEC2006(C/C++) 0.06% (geomean)

> SPEC2017(C/C++) 0.10% (geomean)

> ----------------------------------------------

> Compile time performance for Bootstrapped LLVM

> ----------------------------------------------

> Workload Improvement

> -------- -----------

> SPEC2006(C/C++) 0.41% (cumulative)

> SPEC2017(C/C++) -0.16% (cumulative)

> lnt 0.61% (geomean)

> ----------------------------------------------

> Compile time performance

> ----------------------------------------------

> Workload Increase

> -------- --------

> SPEC2006(C/C++) 1.31% (cumulative)

> SPEC2017(C/C++) 0.25% (cumulative)

> ----------------------------------------------

> Code size

> ----------------------------------------------

> Workload Increase

> -------- --------

> SPEC2006(C/C++) 3.90% (geomean)

> SPEC2017(C/C++) 1.05% (geomean)

>

> NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark

> "astar", which increased by 86%. Removing this outlier, we get a more

> reasonable increase of 0.58%.

>

> NOTE2: There is a patch up for review on Phabricator to enhance the

> partial

> inliner with the presence of profiling information (

>
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D38190&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=6o17wydYZM0l4kPAb3l3cJ95JRPoYb-3l4sHv-R0GaA&e=).

>

>

> Graham Yiu

> LLVM Compiler Development

> IBM Toronto Software Lab

> Office: (905) 413-4077 C2-707/8200/Markham

> Email: [hidden email]

>

> _______________________________________________

> LLVM Developers mailing list

> [hidden email]

>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e=

> Email had 1 attachment:

> + graycol.gif

> 1k (image/gif)

_______________________________________________

LLVM Developers mailing list

[hidden email]

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e=
















_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Adam Nemet via llvm-dev

Hi Graham,

 

I’ve got results of benchmarking. Armv7m and armv6m are not affected. No changes in scores nor code sizes.

I did some additional benchmarks runs for AArch64 and AArch32.

 

LNT test suite, AArch32, Cortex-A57, -O3 -mcpu=cortex-a57 -mthumb -fomit-frame-pointer

-------------------------------------------------------------------------------------------------------------------------

MultiSource/Applications/aha/aha                          6.73% execution time regression

MultiSource/Applications/sqlite3/sqlite3              2.61% execution time improvement

 

Code size regressions greater than 5%:

MultiSource/Benchmarks/MiBench/automotive-susan/automotive-susan             27.07%

MultiSource/Benchmarks/Fhourstones-3.1/fhourstones3.1                                          16.54%

MultiSource/Benchmarks/Olden/bh/bh                                                                                 10.11%

MultiSource/Benchmarks/McCat/18-imp/imp                                                                    8.38%

SingleSource/Benchmarks/Misc-C++/Large/ray                                                                  6.54%

MultiSource/Benchmarks/Prolangs-C/bison/mybison                                                      5.92%

MultiSource/Benchmarks/MallocBench/espresso/espresso                                          5.09%

-------------------------------------------------------------------------------------------------------------------------

 

LNT test suite, AArch64, Cortex-A57, -O3 -mcpu=cortex-a57 -fomit-frame-pointer

-------------------------------------------------------------------------------------------------------------------------

No significant performance improvements/regressions.

 

Code size regressions greater than 5%:

MultiSource/Benchmarks/MiBench/automotive-susan/automotive-susan             24.51%

MultiSource/Benchmarks/McCat/18-imp/imp                                                                    12.99%

MultiSource/Benchmarks/McCat/08-main/main Profile                                                  8.63%

MultiSource/Benchmarks/Olden/bh/bh                                                                                 8.30%

SingleSource/Benchmarks/Shootout-C++/Shootout-C++-hash                                      7.43%

SingleSource/Benchmarks/Misc-C++/bigfib                                                                          6.24%

MultiSource/Benchmarks/Fhourstones-3.1/fhourstones3.1                                          6.10%

MultiSource/Benchmarks/Prolangs-C/agrep/agrep                                                           5.65%

MultiSource/Benchmarks/Ptrdist/yacr2/yacr2                                                                    5.01%

-------------------------------------------------------------------------------------------------------------------------

 

It can be seen there are the same benchmarks have code size regressed. Are they known?

I am still trying to figure out what is wrong with the debug info.

 

Thanks,

Evgeny Astigeevich

 

 

From: Evgeny Astigeevich <[hidden email]>
Date: Friday, 10 November 2017 at 21:28
To: Graham Yiu <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, Tobias Grosser <[hidden email]>
Subject: Re: [llvm-dev] [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 <[hidden email]>
Date: Friday, 10 November 2017 at 16:09
To: Evgeny Astigeevich <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, Tobias Grosser <[hidden email]>
Subject: Re: [llvm-dev] [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: [hidden email]


Inactive hide details for Graham Yiu---11/08/2017 06:00:05 PM---Thanks, Evgeny. Let me know if there's something in the partialGraham Yiu---11/08/2017 06:00:05 PM---Thanks, Evgeny. Let me know if there's something in the partial inlining code that is causing the is

From: Graham Yiu/Toronto/IBM
To: Evgeny Astigeevich <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, "Tobias Grosser" <[hidden email]>
Date: 11/08/2017 06:00 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default




Thanks, Evgeny.

Let me know if there's something in the partial inlining code that is causing the issue(s) you're seeing.

Cheers,

Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]



Inactive hide details for Evgeny Astigeevich ---11/08/2017 05:13:09 PM---Hi Graham, I’ve almost finished my runs. However I’vEvgeny Astigeevich ---11/08/2017 05:13:09 PM---Hi Graham, I’ve almost finished my runs. However I’ve got couple compiler crashes:

From: Evgeny Astigeevich <[hidden email]>
To: Graham Yiu <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, "Tobias Grosser" <[hidden email]>, nd <[hidden email]>
Date: 11/08/2017 05:13 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default





Hi Graham,

I’ve almost finished my runs. However I’ve got couple compiler crashes:

!dbg attachment points at wrong subprogram for function

LLVM ERROR: Broken module found, compilation aborted!

This will take some time to investigate.

Thanks,
Evgeny Astigeevich


From: Graham Yiu <[hidden email]>
Date:
Tuesday, 7 November 2017 at 16:19
To:
Evgeny Astigeevich <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, Tobias Grosser <[hidden email]>
Subject:
Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Hi Evgeny,

When you think the experiments on armv7m and armv6m targets will be complete? We're looking to turn this on sooner rather than later, if there aren't objections from folks running on other platforms.


Cheers,


Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]


Inactive hide details for Graham Yiu---11/03/2017 12:40:10 PM---Hi Evgeny, Yes, please do.  It was our hope that folks would ve
Graham Yiu---11/03/2017 12:40:10 PM---Hi Evgeny, Yes, please do. It was our hope that folks would verify the impact of the partial inline

From:
Graham Yiu/Toronto/IBM
To:
Evgeny Astigeevich <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>, Tobias Grosser <[hidden email]>
Date:
11/03/2017 12:40 PM
Subject:
Re: [llvm-dev] [RFC] Enable Partial Inliner by default





Hi Evgeny,


Yes, please do. It was our hope that folks would verify the impact of the partial inliner on the platforms they're currently working on.


Cheers,


Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: [hidden email]



Inactive hide details for Evgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and armv6m tar
Evgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and armv6m targets, especially code size. We have not tried

From:
Evgeny Astigeevich <[hidden email]>
To:
Tobias Grosser <[hidden email]>, Graham Yiu <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, nd <[hidden email]>
Date:
11/03/2017 12:18 PM
Subject:
Re: [llvm-dev] [RFC] Enable Partial Inliner by default






Hi,



We'd like to check impact on armv7m and armv6m targets, especially code size. We have not tried the partial inliner on them.



Could a decision to turn it on by default wait for results?



Thanks,

Evgeny Astigeevich

The Arm Compiler Optimization team



-----Original Message-----

From: llvm-dev <[hidden email]> on behalf of Tobias Grosser via llvm-dev <[hidden email]>

Reply-To: Tobias Grosser <[hidden email]>

Date: Thursday, 2 November 2017 at 23:32

To: Graham Yiu <[hidden email]>, "[hidden email]" <[hidden email]>

Cc: "[hidden email]" <[hidden email]>

Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default



Hi Graham,



I think this is a good idea. It is also useful for libquantum, where

together with some other changes, it enables Polly to perform libfusion.



The ARM people also played with the partial inliner and might have

feedback.



Best,

Tobias



On Thu, Nov 2, 2017, at 23:05, Graham Yiu via llvm-dev wrote:

>

> 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: [hidden email]

>

>

>

> From: Graham Yiu/Toronto/IBM

> To: [hidden email]

> Cc: [hidden email], [hidden email]

> Date: 11/02/2017 05:26 PM

> Subject: [RFC] Enable Partial Inliner by default

>

>

> Hello,

>

> I'd like to propose turning on the partial inliner

> (-enable-partial-inlining) by default.

>

> We've seen small gains on SPEC2006/2017 runtimes as well as lnt

> compile-times with a 2nd stage bootstrap of LLVM. We also saw positive

> gains on our internal workloads.

>

> -------------------------------------

> Brief description of Partial Inlining

> -------------------------------------

> A pass in opt that runs after the normal inlining pass. Looks for

> branches

> to a return block in the entry and immediate successor blocks of a

> function. If found, it outlines the rest of the function using the

> CodeExtractor. It then attempts to inline the leftover entry block (and

> possibly one or more of its successors) to all its callers. This

> effectively peels the early return block(s) into the caller, which could

> be

> executed without incurring the call overhead of the function just to

> return

> immediately. Inlining and call overhead cost, as well as branch

> probabilities of the return block(s) are taken into account before

> inlining

> is done. If inlining is not successful, then the changes are discarded.

>

> eg.

>

> void foo() {

> bar();

> // rest of the code in foo

> }

>

> void bar() {

> if (X)

> return;

> // rest of code (to be outlined)

> }

>

> After Partial Inlining:

>

> void foo() {

> if (!X)

> bar.outlined();

> // rest of the code in foo

> }

>

> void bar.outlined() {

> // rest of the code in bar

> }

>

>

> Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode

>

> ----------------------------------------------

> Runtime performance (speed)

> ----------------------------------------------

> Workload Improvement

> -------- -----------

> SPEC2006(C/C++) 0.06% (geomean)

> SPEC2017(C/C++) 0.10% (geomean)

> ----------------------------------------------

> Compile time performance for Bootstrapped LLVM

> ----------------------------------------------

> Workload Improvement

> -------- -----------

> SPEC2006(C/C++) 0.41% (cumulative)

> SPEC2017(C/C++) -0.16% (cumulative)

> lnt 0.61% (geomean)

> ----------------------------------------------

> Compile time performance

> ----------------------------------------------

> Workload Increase

> -------- --------

> SPEC2006(C/C++) 1.31% (cumulative)

> SPEC2017(C/C++) 0.25% (cumulative)

> ----------------------------------------------

> Code size

> ----------------------------------------------

> Workload Increase

> -------- --------

> SPEC2006(C/C++) 3.90% (geomean)

> SPEC2017(C/C++) 1.05% (geomean)

>

> NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark

> "astar", which increased by 86%. Removing this outlier, we get a more

> reasonable increase of 0.58%.

>

> NOTE2: There is a patch up for review on Phabricator to enhance the

> partial

> inliner with the presence of profiling information (

>
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D38190&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=6o17wydYZM0l4kPAb3l3cJ95JRPoYb-3l4sHv-R0GaA&e=).

>

>

> Graham Yiu

> LLVM Compiler Development

> IBM Toronto Software Lab

> Office: (905) 413-4077 C2-707/8200/Markham

> Email: [hidden email]

>

> _______________________________________________

> LLVM Developers mailing list

> [hidden email]

>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e=

> Email had 1 attachment:

> + graycol.gif

> 1k (image/gif)

_______________________________________________

LLVM Developers mailing list

[hidden email]

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e=

















_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
12