similar to: [ThinLTO] Importing based on PGO data

2016-09-02 15:04 GMT-07:00 Xinliang David Li <davidxl at google.com>: > On Fri, Sep 2, 2016 at 2:58 PM, Piotr Padlewski > <piotr.padlewski at gmail.com> wrote: > > Hi, > > I am working right now on importing based on PGO/FDO data. There is one > > issue that I found - when we calculate the list of imports, we can't get > the > > ProfileSummaryInfo,

On Fri, Sep 2, 2016 at 3:30 PM, Xinliang David Li <davidxl at google.com> wrote: > On Fri, Sep 2, 2016 at 3:16 PM, Piotr Padlewski > <piotr.padlewski at gmail.com> wrote: > > > > > > 2016-09-02 15:04 GMT-07:00 Xinliang David Li <davidxl at google.com>: > >> > >> On Fri, Sep 2, 2016 at 2:58 PM, Piotr Padlewski > >>

The profile summary is saved in the global metadata ASAIK. If we want to calculate if something is hot/cold while choosing functions for importing, we would either need to read whole Module (which we clearly don't want to do) or duplicate this information in the summary, so we could get it without reading Module. 2016-09-02 15:49 GMT-07:00 Mehdi Amini <mehdi.amini at apple.com>: >

Hi Jhonny, Thanks for your interest in ThinLTO! Are you looking for a summer project, or ongoing work in compilers, or clang/llvm specifically? Are you a student? Note that these were project ideas for Google Summer of Code. The GSoC application deadline has passed and we did have a student apply to work on this particular project. So if that application ends up being accepted then we will have

Good evening. I got interested in helping with ThinLTO, I did watch this video, https://youtu.be/9OIEZAj243g and i found it very interesting. I got C++ knowledge, but not a lot of llvm/clang source knowledge... Also, there is no mentors related in the website for this project. Would the community be so kind in giving me information on how to help? I have started reading the documentation on the

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. >> >

Hi Teresa, Actually, enabling the new pass manager manually seems to have solved this issue, so this problem is only valid for the old pass manager. Thanks, Graham Yiu LLVM Compiler Development IBM Toronto Software Lab Office: (905) 413-4077 C2-707/8200/Markham Email: gyiu at ca.ibm.com From: Teresa Johnson <tejohnson at google.com> To: Graham Yiu <gyiu at ca.ibm.com> Cc:

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

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

Interesting. By ld do you mean GNU ld? I know GNU ld does "work" with LLVM's gold plugin, but it's an untested combination and not recommended. I wouldn't be surprised if there were some issues around it not passing necessary info to the gold plugin. Teresa On Mon, Sep 16, 2019 at 8:41 AM Michael Woerister <mwoerister at mozilla.com> wrote: > So one interesting

To give a little update here: - I've been further investigating and found an issue [1] with the Cargo build tool that most Rust projects use. This issue prevents all projects using Cargo from properly using PGO because it causes symbol names to be different between the generate and the use phase. With this issue fixed the number of "No profile data available for function" warnings

On Thu, Sep 12, 2019 at 8:18 AM Teresa Johnson <tejohnson at google.com> wrote: > I just have a couple suggestions off the top of my head: > - have you tried using the new pass manager > (-fexperimental-new-pass-manager)? That has access to additional analysis > info during inlining and is able to make more precise PGO based inline > decisions. > (although note the above

Can you clarify if performance difference is caused by using different linkers at instrumentation build? If that is the case, try dump the sections of the resulting binary and compare __llvm_prf_** sections. Also check the arguments passed to the linker. It should have -u__llvm_profile_runtime to force the profile runtime to be linked in. David On Mon, Sep 16, 2019 at 8:42 AM Michael

Hi all, To implement more profile-guided optimizations, we’d like to use ProfileSummaryInfo (PSI) and BlockFrequencyInfo (BFI) from more passes of various types, under the new pass manager. The following is what we came up with. Would appreciate feedback. Thanks. Issue It’s not obvious (to me) how to best do this, given that we cannot request an outer-scope analysis result from an inner-scope

No worries, thanks for the update. Teresa On Mon, Sep 26, 2016, 7:16 AM Carsten Mattner <carstenmattner at gmail.com> wrote: > On Mon, Sep 26, 2016 at 3:52 PM, Teresa Johnson <tejohnson at google.com> > wrote: > > > > ThinLTO needs to create as many temporary files as there are input > > modules to the link. From your 'ls' below, it doesn't look

Hi, Thanks for the info, If i only want to run performance test on benchmarks for LTO and Thin LTO enabled target, Can u suggest ways to do it ? I want to do it at my end. Thanks, Siddharth On Wed, May 2, 2018 at 7:03 PM, Teresa Johnson <tejohnson at google.com> wrote: > I've only measured performance on x86. There are some old results for SPEC > cpu2006 in the blog post here:

Here's a sketch of the proposed approach for just one pass (but imagine more) https://reviews.llvm.org/D58845 On Fri, Mar 1, 2019 at 12:54 PM Fedor Sergeev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 2/28/19 12:47 AM, Hiroshi Yamauchi via llvm-dev wrote: > > Hi all, > > To implement more profile-guided optimizations, we’d like to use > ProfileSummaryInfo

Interestingly, a C version of the same test program [1] compiled with Clang 8 does not have any problems with GNU ld: The `__llvm_prf_data` section is the same size for all three linkers. It must be something specific to the Rust compiler that's going wrong here. [1] https://github.com/michaelwoerister/rust-pgo-test-programs/tree/master/cpp_branch_weights On Tue, Sep 17, 2019 at 3:26 PM

Yes running LLVM performance test suite with LTO and Thin LTO enabled. Thanks, Siddharth On Fri, May 11, 2018 at 7:32 PM, Teresa Johnson <tejohnson at google.com> wrote: > I'm not completely sure what you are asking. Are you looking for > performance benchmarks to use for LTO and ThinLTO testing? Or are you > asking how to build/run with LTO and ThinLTO? Are you asking how to

On Mon, Sep 26, 2016 at 8:08 AM, Carsten Mattner <carstenmattner at gmail.com> wrote: > On Mon, Sep 26, 2016 at 4:25 PM, Teresa Johnson <tejohnson at google.com> > wrote: > > No worries, thanks for the update. Teresa > > 2048 wasn't enough. Bumped to 4096. Only 1300 ninja targets left. > > Once I've been successful with this, I might try building a