llvm dev - Mar 2016 - Profile-based inlining status

Hello,

I'm learning how LLVM performs PGO (profile-guided optimizations) by using
the instrumentation-based profile build (-fprofile-instr-generate and
-fprofile-instr-use).
However, I found there is no difference in inlining behaviors between with
and without PGO for a few spec benchmarks by checking the emit optimization
reports (-Rpass=inline -Rpass-missed=inline -Rpass-analysis=inline). Also,
the profile information collected contains only block counters, not call
counters. This seems to indicate that the profile-based inlining is not
supported yet (my LLVM/Clang is 3.9.0, mid Feb trunk). Is this the case?

The talk in the LLVM conference 2013 (
http://llvm.org/devmtg/2013-11/slides/Carruth-PGO.pdf) actually describes
that "the inliner doesn't even know profile information exists
today" (page
89), but it's been more than two years since that statement. Can you let me
know the latest status or any ongoing work for the profile-based inlining
(both same-module and cross-module inlining)?

Thank you,
--Toshio
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160308/3482eb5d/attachment.html>

> On Mar 7, 2016, at 8:58 AM, Toshio Suganuma via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hello,
> 
> I'm learning how LLVM performs PGO (profile-guided optimizations) by
using the instrumentation-based profile build (-fprofile-instr-generate and
-fprofile-instr-use).
> However, I found there is no difference in inlining behaviors between with
and without PGO for a few spec benchmarks by checking the emit optimization
reports (-Rpass=inline -Rpass-missed=inline -Rpass-analysis=inline). Also, the
profile information collected contains only block counters, not call counters.
> 
Since a call is necessarily in a block, I'm not sure what extra information
you would get with a call counter?
> This seems to indicate that the profile-based inlining is not supported yet
(my LLVM/Clang is 3.9.0, mid Feb trunk). Is this the case?
> 
> The talk in the LLVM conference 2013
(http://llvm.org/devmtg/2013-11/slides/Carruth-PGO.pdf
<http://llvm.org/devmtg/2013-11/slides/Carruth-PGO.pdf>) actually
describes that "the inliner doesn't even know profile information
exists today" (page 89), but it's been more than two years since that
statement. Can you let me know the latest status or any ongoing work for the
profile-based inlining (both same-module and cross-module inlining)?
> 
I believe it was added recently (last December, see
http://reviews.llvm.org/D15245 ), so a trunk version should definitely have it.

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160307/9bd3526e/attachment.html>

You are right that inliner does not yet know profile information at
callsite level (only knows about if callee is hot -- later is also not
correct as it is not updated at all).

We are working on this. A patch was committed to enable profile/profile
update in inliner recently, but got temporarily reverted for further
discussion. We will announce it once the feature is in trunk.

thanks,

David

On Mon, Mar 7, 2016 at 8:58 AM, Toshio Suganuma via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello,
>
> I'm learning how LLVM performs PGO (profile-guided optimizations) by
using
> the instrumentation-based profile build (-fprofile-instr-generate and
> -fprofile-instr-use).
> However, I found there is no difference in inlining behaviors between with
> and without PGO for a few spec benchmarks by checking the emit optimization
> reports (-Rpass=inline -Rpass-missed=inline -Rpass-analysis=inline). Also,
> the profile information collected contains only block counters, not call
> counters. This seems to indicate that the profile-based inlining is not
> supported yet (my LLVM/Clang is 3.9.0, mid Feb trunk). Is this the case?
>
> The talk in the LLVM conference 2013 (
> http://llvm.org/devmtg/2013-11/slides/Carruth-PGO.pdf) actually describes
> that "the inliner doesn't even know profile information exists
today" (page
> 89), but it's been more than two years since that statement. Can you
let me
> know the latest status or any ongoing work for the profile-based inlining
> (both same-module and cross-module inlining)?
>
> Thank you,
> --Toshio
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160308/3ff13448/attachment.html>

On Mon, Mar 7, 2016 at 11:42 PM, Mehdi Amini via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> On Mar 7, 2016, at 8:58 AM, Toshio Suganuma via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hello,
>
> I'm learning how LLVM performs PGO (profile-guided optimizations) by
using
> the instrumentation-based profile build (-fprofile-instr-generate and
> -fprofile-instr-use).
> However, I found there is no difference in inlining behaviors between with
> and without PGO for a few spec benchmarks by checking the emit optimization
> reports (-Rpass=inline -Rpass-missed=inline -Rpass-analysis=inline). Also,
> the profile information collected contains only block counters, not call
> counters.
>
> Since a call is necessarily in a block, I'm not sure what extra
> information you would get with a call counter?
>
> This seems to indicate that the profile-based inlining is not supported
> yet (my LLVM/Clang is 3.9.0, mid Feb trunk). Is this the case?
>
> The talk in the LLVM conference 2013 (
> http://llvm.org/devmtg/2013-11/slides/Carruth-PGO.pdf) actually describes
> that "the inliner doesn't even know profile information exists
today" (page
> 89), but it's been more than two years since that statement. Can you
let me
> know the latest status or any ongoing work for the profile-based inlining
> (both same-module and cross-module inlining)?
>
> I believe it was added recently (last December, see
> http://reviews.llvm.org/D15245 ), so a trunk version should definitely
> have it.
>
There is a more recent patch that does the whole thing (including
incremental update) that is under review.

David

>
> --
> Mehdi
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160308/c6cd6bee/attachment.html>