[llvm-dev] PGO information at LTO/thinLTO link step

Tue Oct 3 14:10:21 PDT 2017

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>