Graham Yiu via llvm-dev
2017-Oct-03 21:10 UTC
[llvm-dev] PGO information at LTO/thinLTO link step
Thanks Easwaran. This is what we've observed as well, where the old PM
inliner was only looking hot/cold callee information, which have
signficantly smaller boosts/penalties compared to callsite information.
Teresa, do you know if there is some documentation/video/presentation on
how PGO information is represented in LLVM and what information is passed
via the IR? I'm finding some difficulty in getting the big picture via the
code.
Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: gyiu at ca.ibm.com
From: Teresa Johnson <tejohnson at google.com>
To: Easwaran Raman <eraman at google.com>
Cc: Graham Yiu <gyiu at ca.ibm.com>, llvm-dev
<llvm-dev at lists.llvm.org>
Date: 10/03/2017 05:00 PM
Subject: Re: [llvm-dev] PGO information at LTO/thinLTO link step
On Tue, Oct 3, 2017 at 1:55 PM, Easwaran Raman <eraman at google.com>
wrote:
On Tue, Oct 3, 2017 at 1:46 PM, Teresa Johnson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
On Tue, Oct 3, 2017 at 1:38 PM, Graham Yiu <gyiu at ca.ibm.com> wrote:
Hi Teresa,
Actually, enabling the new pass manager manually seems to have solved
this issue, so this problem is only valid for the old pass manager.
It should not be an issue in the old PM either - the callsite hotness is
passed via IR.
More precisely, the function entry counts are passed via IR. With the old
PM, we don't have callsite hotness information, but callee's entry
count
is used to boost the threshold.
Thanks for the clarification. (But essentially there should be no
difference between the profile info in the IR in the compile step vs the
link aka ThinLTO backend steps - the inliner in both cases is working off
the same profile info in the IR)
As David mentioned, the new PM inliner does a better job of updating
call hotness after inlining, but it should be there (some things might
look hotter than then should, which seems to be the opposite of the
problem you are hitting). Can you send me a reproducer with the old PM?
Teresa
Thanks,
Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: gyiu at ca.ibm.com
Inactive hide details for Teresa Johnson ---10/03/2017 04:18:17
PM---On Tue, Oct 3, 2017 at 12:54 PM, Graham Yiu via llvm-dev <Teresa
Johnson ---10/03/2017 04:18:17 PM---On Tue, Oct 3, 2017 at 12:54 PM,
Graham Yiu via llvm-dev < llvm-dev at lists.llvm.org> wrote:
From: Teresa Johnson <tejohnson at google.com>
To: Graham Yiu <gyiu at ca.ibm.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Date: 10/03/2017 04:18 PM
Subject: Re: [llvm-dev] PGO information at LTO/thinLTO link step
On Tue, Oct 3, 2017 at 12:54 PM, Graham Yiu via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
Hello,
My team and I noticed that callsite hotness information is not
preserved from compile to link step with LTO/thinLTO enabled. As
a result, the link step inlining pass remains conservative when
inlining callsites known to be hot (ie. without the
'HotCallSiteThreshold' which is set at 3000 by default).
There
are likely many cross-module inlining opportunities lost this
way, and diminishes the benefit of using LTO/thinLTO+PGO
together.
The callsite hotness is passed via the IR, so it should be there in
the LTO/ThinLTO backends (during the link step). Can you provide a
reproducer where that isn't happening?
Teresa
In general, does LLVM pass profiling information through the IR
to the link step other than branch probabilities and function
entry counts? If not, are there plans to do so in the future?
For inlining specifically, perhaps we can mark callsites with
hot/cold attributes during compile step to ensure LTO inlining
will give appropriate threshold bonuses/penalties.
Any thoughts/insights/comments would be appreciated.
Cheers,
Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: gyiu at ca.ibm.com
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--
|-----------+-------------+--------------------+------------|
|Teresa | Software | | |
|Johnson | |Engineer | |tejohnson at google.com|408-460-2413|
| | || | |
|-----------+-------------+--------------------+------------|
--
-----------------------------------------------------------
Teresa Software
Johnson | Engineer | tejohnson at google.com 408-460-2413
|
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--
-----------------------------------------------------------
Teresa Software
Johnson | Engineer | tejohnson at google.com 408-460-2413
|
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/d89f26e7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/d89f26e7/attachment.gif>
Teresa Johnson via llvm-dev
2017-Oct-03 21:15 UTC
[llvm-dev] PGO information at LTO/thinLTO link step
On Tue, Oct 3, 2017 at 2:10 PM, Graham Yiu <gyiu at ca.ibm.com> wrote:> Thanks Easwaran. This is what we've observed as well, where the old PM > inliner was only looking hot/cold callee information, which have > signficantly smaller boosts/penalties compared to callsite information. > > Teresa, do you know if there is some documentation/video/presentation on > how PGO information is represented in LLVM and what information is passed > via the IR? I'm finding some difficulty in getting the big picture via the > code. >The documentation I am aware of is in the Language Ref and a subpage linked from here: https://llvm.org/docs/LangRef.html#prof-metadata If that doesn't help let me know and I can point you to someone who would know (if I can't answer it myself). Teresa> > > Graham Yiu > LLVM Compiler Development > IBM Toronto Software Lab > Office: (905) 413-4077 C2-707/8200/Markham > Email: gyiu at ca.ibm.com > > [image: Inactive hide details for Teresa Johnson ---10/03/2017 05:00:11 > PM---On Tue, Oct 3, 2017 at 1:55 PM, Easwaran Raman <eraman at goo]Teresa > Johnson ---10/03/2017 05:00:11 PM---On Tue, Oct 3, 2017 at 1:55 PM, > Easwaran Raman <eraman at google.com> wrote: > > > From: Teresa Johnson <tejohnson at google.com> > To: Easwaran Raman <eraman at google.com> > Cc: Graham Yiu <gyiu at ca.ibm.com>, llvm-dev <llvm-dev at lists.llvm.org> > Date: 10/03/2017 05:00 PM > > Subject: Re: [llvm-dev] PGO information at LTO/thinLTO link step > ------------------------------ > > > > > > On Tue, Oct 3, 2017 at 1:55 PM, Easwaran Raman <*eraman at google.com* > <eraman at google.com>> wrote: > > > > On Tue, Oct 3, 2017 at 1:46 PM, Teresa Johnson via llvm-dev < > *llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org>> wrote: > > > On Tue, Oct 3, 2017 at 1:38 PM, Graham Yiu <*gyiu at ca.ibm.com* > <gyiu at ca.ibm.com>> wrote: > Hi Teresa, > > Actually, enabling the new pass manager manually seems to have > solved this issue, so this problem is only valid for the old pass manager. > > > It should not be an issue in the old PM either - the callsite hotness > is passed via IR. > More precisely, the function entry counts are passed via IR. With the > old PM, we don't have callsite hotness information, but callee's entry > count is used to boost the threshold. > > > Thanks for the clarification. (But essentially there should be no > difference between the profile info in the IR in the compile step vs the > link aka ThinLTO backend steps - the inliner in both cases is working off > the same profile info in the IR) > > > As David mentioned, the new PM inliner does a better job of updating > call hotness after inlining, but it should be there (some things might look > hotter than then should, which seems to be the opposite of the problem you > are hitting). Can you send me a reproducer with the old PM? > > Teresa > > > Thanks, > > Graham Yiu > LLVM Compiler Development > IBM Toronto Software Lab > Office: *(905) 413-4077* <(905)%20413-4077> C2-707/8200/Markham > Email: *gyiu at ca.ibm.com* <gyiu at ca.ibm.com> > > [image: Inactive hide details for Teresa Johnson ---10/03/2017 > 04:18:17 PM---On Tue, Oct 3, 2017 at 12:54 PM, Graham Yiu via llvm-dev <]Teresa > Johnson ---10/03/2017 04:18:17 PM---On Tue, Oct 3, 2017 at 12:54 PM, Graham > Yiu via llvm-dev < *llvm-dev at lists.llvm.org* > <llvm-dev at lists.llvm.org>> wrote: > > From: Teresa Johnson <*tejohnson at google.com* <tejohnson at google.com>> > To: Graham Yiu <*gyiu at ca.ibm.com* <gyiu at ca.ibm.com>> > Cc: llvm-dev <*llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org>> > Date: 10/03/2017 04:18 PM > Subject: Re: [llvm-dev] PGO information at LTO/thinLTO link step > ------------------------------ > > > > > > > On Tue, Oct 3, 2017 at 12:54 PM, Graham Yiu via llvm-dev < > *llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org>> wrote: > Hello, > > My team and I noticed that callsite hotness information is > not preserved from compile to link step with LTO/thinLTO enabled. As a > result, the link step inlining pass remains conservative when inlining > callsites known to be hot (ie. without the 'HotCallSiteThreshold' which is > set at 3000 by default). There are likely many cross-module inlining > opportunities lost this way, and diminishes the benefit of using > LTO/thinLTO+PGO together. > > > The callsite hotness is passed via the IR, so it should be there in > the LTO/ThinLTO backends (during the link step). Can you provide a > reproducer where that isn't happening? > Teresa > > > In general, does LLVM pass profiling information through the > IR to the link step other than branch probabilities and function entry > counts? If not, are there plans to do so in the future? For inlining > specifically, perhaps we can mark callsites with hot/cold attributes during > compile step to ensure LTO inlining will give appropriate threshold > bonuses/penalties. > > Any thoughts/insights/comments would be appreciated. > > Cheers, > > Graham Yiu > LLVM Compiler Development > IBM Toronto Software Lab > Office: *(905) 413-4077* <(905)%20413-4077> > C2-707/8200/Markham > Email: *gyiu at ca.ibm.com* <gyiu at ca.ibm.com> > > _______________________________________________ > LLVM Developers mailing list > *llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org> > *http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev* > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=843dScatsnrNnnksXYIg_bhjifer5nLwDpeZvFGhfsY&s=ophNPzRTV6yMQdp3RxwwiV4szFjf6F8lnEyy9Y5paxw&e=> > > > > -- > Teresa Johnson | Software Engineer | *tejohnson at google.com* > <tejohnson at google.com> | *408-460-2413* <(408)%20460-2413> > > > > > > -- > Teresa Johnson | Software Engineer | *tejohnson at google.com* > <tejohnson at google.com> | *408-460-2413* <(408)%20460-2413> > _______________________________________________ > LLVM Developers mailing list > *llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org> > *http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev* > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=38hnZvEzFyovf0wgsdGGbzKq028feXdugel47ntZ4Lo&s=SfjVDeS9ryb7NpC-k_7Igt-khIsUZXWe76rgwPv3aVA&e=> > > > > > > -- > Teresa Johnson | Software Engineer | *tejohnson at google.com* > <tejohnson at google.com> | 408-460-2413 <(408)%20460-2413> > > >-- Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/67d3f433/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/67d3f433/attachment.gif>
Xinliang David Li via llvm-dev
2017-Oct-03 21:34 UTC
[llvm-dev] PGO information at LTO/thinLTO link step
On Tue, Oct 3, 2017 at 2:15 PM, Teresa Johnson via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > > On Tue, Oct 3, 2017 at 2:10 PM, Graham Yiu <gyiu at ca.ibm.com> wrote: > >> Thanks Easwaran. This is what we've observed as well, where the old PM >> inliner was only looking hot/cold callee information, which have >> signficantly smaller boosts/penalties compared to callsite information. >> >> Teresa, do you know if there is some documentation/video/presentation on >> how PGO information is represented in LLVM and what information is passed >> via the IR? I'm finding some difficulty in getting the big picture via the >> code. >> >In a nutshell, there are two main types of profile data (BB/edge related). 1) branch probability 2) function entry count. PGO instrumentation actually collects BB count. During profile annotation pass, the branch probability (weights) profile data is computed and annotated to the IR (the branch instructions). After profile annotation, the block count information is dropped except for the function entry count which is annotated to the function entry. The BPI/BFI pass can recompute the block frequency data from the branch probability info. The BB frequency is intra-function and does not have global meaning. To recompute the profile count for a BB, function entry profile count is used, which is multiplied by the ratio of the BB freq and entry freq. This scheme works really well except for CFG with irreducible loops, for which BFI's frequency propagation pass can not reconstruct the frequency/count properly. Hiroshi is working on a patch to fix the problem. For AutoFDO, there is also a sample count profile for callsites which is needed because function entry may not have any samples. The value profiler also has its meta data for value histograms of a given value site. At module level, while program profile summary data is also represented so that optimization passes can query for global hotness info. David> > The documentation I am aware of is in the Language Ref and a subpage > linked from here: > https://llvm.org/docs/LangRef.html#prof-metadata > > If that doesn't help let me know and I can point you to someone who would > know (if I can't answer it myself). > > Teresa > >> >> >> Graham Yiu >> LLVM Compiler Development >> IBM Toronto Software Lab >> Office: (905) 413-4077 C2-707/8200/Markham >> Email: gyiu at ca.ibm.com >> >> [image: Inactive hide details for Teresa Johnson ---10/03/2017 05:00:11 >> PM---On Tue, Oct 3, 2017 at 1:55 PM, Easwaran Raman <eraman at goo]Teresa >> Johnson ---10/03/2017 05:00:11 PM---On Tue, Oct 3, 2017 at 1:55 PM, >> Easwaran Raman <eraman at google.com> wrote: > >> >> From: Teresa Johnson <tejohnson at google.com> >> To: Easwaran Raman <eraman at google.com> >> Cc: Graham Yiu <gyiu at ca.ibm.com>, llvm-dev <llvm-dev at lists.llvm.org> >> Date: 10/03/2017 05:00 PM >> >> Subject: Re: [llvm-dev] PGO information at LTO/thinLTO link step >> ------------------------------ >> >> >> >> >> >> On Tue, Oct 3, 2017 at 1:55 PM, Easwaran Raman <*eraman at google.com* >> <eraman at google.com>> wrote: >> >> >> >> On Tue, Oct 3, 2017 at 1:46 PM, Teresa Johnson via llvm-dev < >> *llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org>> wrote: >> >> >> On Tue, Oct 3, 2017 at 1:38 PM, Graham Yiu <*gyiu at ca.ibm.com* >> <gyiu at ca.ibm.com>> wrote: >> Hi Teresa, >> >> Actually, enabling the new pass manager manually seems to have >> solved this issue, so this problem is only valid for the old pass manager. >> >> >> It should not be an issue in the old PM either - the callsite hotness >> is passed via IR. >> More precisely, the function entry counts are passed via IR. With the >> old PM, we don't have callsite hotness information, but callee's entry >> count is used to boost the threshold. >> >> >> Thanks for the clarification. (But essentially there should be no >> difference between the profile info in the IR in the compile step vs the >> link aka ThinLTO backend steps - the inliner in both cases is working off >> the same profile info in the IR) >> >> >> As David mentioned, the new PM inliner does a better job of updating >> call hotness after inlining, but it should be there (some things might look >> hotter than then should, which seems to be the opposite of the problem you >> are hitting). Can you send me a reproducer with the old PM? >> >> Teresa >> >> >> Thanks, >> >> Graham Yiu >> LLVM Compiler Development >> IBM Toronto Software Lab >> Office: *(905) 413-4077* <(905)%20413-4077> C2-707/8200/Markham >> Email: *gyiu at ca.ibm.com* <gyiu at ca.ibm.com> >> >> [image: Inactive hide details for Teresa Johnson ---10/03/2017 >> 04:18:17 PM---On Tue, Oct 3, 2017 at 12:54 PM, Graham Yiu via llvm-dev <]Teresa >> Johnson ---10/03/2017 04:18:17 PM---On Tue, Oct 3, 2017 at 12:54 PM, Graham >> Yiu via llvm-dev < *llvm-dev at lists.llvm.org* >> <llvm-dev at lists.llvm.org>> wrote: >> >> From: Teresa Johnson <*tejohnson at google.com* <tejohnson at google.com> >> > >> To: Graham Yiu <*gyiu at ca.ibm.com* <gyiu at ca.ibm.com>> >> Cc: llvm-dev <*llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org>> >> Date: 10/03/2017 04:18 PM >> Subject: Re: [llvm-dev] PGO information at LTO/thinLTO link step >> ------------------------------ >> >> >> >> >> >> >> On Tue, Oct 3, 2017 at 12:54 PM, Graham Yiu via llvm-dev < >> *llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org>> wrote: >> Hello, >> >> My team and I noticed that callsite hotness information is >> not preserved from compile to link step with LTO/thinLTO enabled. As a >> result, the link step inlining pass remains conservative when inlining >> callsites known to be hot (ie. without the 'HotCallSiteThreshold' which is >> set at 3000 by default). There are likely many cross-module inlining >> opportunities lost this way, and diminishes the benefit of using >> LTO/thinLTO+PGO together. >> >> >> The callsite hotness is passed via the IR, so it should be there >> in the LTO/ThinLTO backends (during the link step). Can you provide a >> reproducer where that isn't happening? >> Teresa >> >> >> In general, does LLVM pass profiling information through the >> IR to the link step other than branch probabilities and function entry >> counts? If not, are there plans to do so in the future? For inlining >> specifically, perhaps we can mark callsites with hot/cold attributes during >> compile step to ensure LTO inlining will give appropriate threshold >> bonuses/penalties. >> >> Any thoughts/insights/comments would be appreciated. >> >> Cheers, >> >> Graham Yiu >> LLVM Compiler Development >> IBM Toronto Software Lab >> Office: *(905) 413-4077* <(905)%20413-4077> >> C2-707/8200/Markham >> Email: *gyiu at ca.ibm.com* <gyiu at ca.ibm.com> >> >> _______________________________________________ >> LLVM Developers mailing list >> *llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org> >> *http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev* >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=843dScatsnrNnnksXYIg_bhjifer5nLwDpeZvFGhfsY&s=ophNPzRTV6yMQdp3RxwwiV4szFjf6F8lnEyy9Y5paxw&e=> >> >> >> >> -- >> Teresa Johnson | Software Engineer | *tejohnson at google.com* >> <tejohnson at google.com> | *408-460-2413* <(408)%20460-2413> >> >> >> >> >> >> -- >> Teresa Johnson | Software Engineer | *tejohnson at google.com* >> <tejohnson at google.com> | *408-460-2413* <(408)%20460-2413> >> _______________________________________________ >> LLVM Developers mailing list >> *llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org> >> *http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev* >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=38hnZvEzFyovf0wgsdGGbzKq028feXdugel47ntZ4Lo&s=SfjVDeS9ryb7NpC-k_7Igt-khIsUZXWe76rgwPv3aVA&e=> >> >> >> >> >> >> -- >> Teresa Johnson | Software Engineer | *tejohnson at google.com* >> <tejohnson at google.com> | 408-460-2413 <(408)%20460-2413> >> >> >> > > > -- > Teresa Johnson | Software Engineer | tejohnson at google.com | > 408-460-2413 <(408)%20460-2413> > > _______________________________________________ > 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/20171003/5597d580/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/5597d580/attachment.gif>