similar to: [RFC] New Feature Proposal: De-Optimizing Cold Functions using PGO Info

Hello, We use PGO to optimize clang itself. I can see if I have time to give this patch some testing. Anything special to look out for except compile benchmark and time to build clang, do you expect any changes in code size? On Wed, Sep 9, 2020, 10:03 Renato Golin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, 9 Sep 2020 at 01:21, Min-Yih Hsu via llvm-dev < >

On Wed, 9 Sep 2020 at 19:26, Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > - Default (i.e. no -profile-deopt-cold): do nothing > - Option with no arg (i.e. -profile-deopt-cold): add attribute only to > functions that have an execution count of zero > - Option with an arg (i.e. -profile-deopt-cold=<N>): add attribute to > functions that account for <N>% of

On Wed, 9 Sep 2020 at 18:15, Min-Yih Hsu via llvm-dev < llvm-dev at lists.llvm.org> wrote: > David mentioned in D87337 that LLVM has used similar techniques on code > size (not sure what he was referencing, my guess will be something related > to hot-cold code splitting). > IIUC, it's just using optsize instead of optnone. The idea is that, if the code really doesn't

On Wed, Sep 9, 2020 at 9:23 PM Wenlei He via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think calling PGSO size opt is probably a bit misleading though. It’s > more of an adaptive opt strategy, and it can improve performance too due to > better locality. We have something similar internally for selecting opt > level based on profile hotness too under AutoFDO. > >

FYI David is referring to PGSO (profile-guided size optimization) as it exists directly under that name, see: https://reviews.llvm.org/D67120. And yeah using PGSO is selecting optsize while this change is selecting optnone. On 9/9/20, 10:58 AM, "llvm-dev on behalf of Tobias Hieta via llvm-dev" <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org> on

On Wed, 9 Sep 2020 at 14:27, Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > A more aesthetic comment I have is that personally, I would prefer a > single option with a default percentage (say 0%) rather than having to > specify two options. > 0% doesn't mean "don't do it", just means "only do that to functions I didn't see running at

Hi All, Recently we discovered a (hidden) performance bug that happened when you’re using Full LTO setup + BFD linker to compile first-stage PGO executables that were expected to generate IR level profile files. That is, compiling an executable using following commands: ``` clang -flto -fprofile-generate -c sample.c -o sample.c.bc.o clang -flto sample.c.bc.o -o sample_exe -fprofile-generate ```

Hello, I am Ruijie Fang, a GSoC student working on "Improve hot cold splitting to aggressively outline small blocks." Over the course of last week, I met with my mentor and co-mentor, Aditya Kumar, and Rodrigo Rocha, and we made a preliminary plan on improving the existing hot/cold splitting pass in LLVM through identifying patterns of cold blocks in real-world workloads via block

Hi Teresa, Thank you for your reply! I discussed this with Aditya and Rodrigo today about this. We will always have PGO turned on for our benchmark, (i.e. we assume the profiling information is always available). In terms of the workload we supply to PGO: For postgresql, I suggested we use the "pgbench" benchmark, a TPC-B-based SQL benchmark for postgres, to supply profiling information

Hello Tobias, Thank you for the suggestion! Aditya also mentioned this. I will look into it. Best regards, Ruijie Ruijie Fang Email: ruijief at princeton.edu On Tue, Jun 2, 2020 at 12:48 PM Tobias Hieta <tobias at plexapp.com> wrote: > Hello Ruijie, > > One other workload that would be interesting to test might be clang > itself. Building clang with PGO information is a

> On 2015 May 27, at 07:42, Diego Novillo <dnovillo at google.com> wrote: > > On Tue, May 26, 2015 at 11:47 PM, Lee Hunt <leehu at exchange.microsoft.com> wrote: > >> For example, from reading different pages on how Clang PGO, it’s unclear if >> it does “block reordering” (i.e. moving unexecuted code blocks to a distant >> code page, leaving only ‘hot’

On 05/27/2015 11:13 AM, Duncan P. N. Exon Smith wrote: >> On 2015 May 27, at 07:42, Diego Novillo <dnovillo at google.com> wrote: >> >> On Tue, May 26, 2015 at 11:47 PM, Lee Hunt <leehu at exchange.microsoft.com> wrote: >> >>> For example, from reading different pages on how Clang PGO, it’s unclear if >>> it does “block reordering” (i.e. moving

Hi everybody, I'm trying to get loop hotness data across a suite (e.g. the llvm test-suite). Ideally, this would be a list that for each loop would list how many times it was entered and what was its iteration count (at least the latter). The closest thing I could come up with is: - clang -fprofile-instr-generate (without opts) to get a .profraw - Get the .profdata - Give that back to clang

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, which is the best and I think only valid way of checking if callsite/callee is hot (isHotCount()). There are 2 solutions that I come up with Teresa and Easwaran: 1. Add PGO data to summary 2. Replace

Thanks for testing out LLVM PGO and evaluated the performance. We are currently still more focused on infrastructure improvement which is the foundation for performance improvement. We are making great progress in this direction, but there are still some key missing pieces such as profile data in inliner etc. We are working on that. Once those are done, more focus will be on making more passes

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 everyone, As part of my work for Mozilla's Low Level Tools team I've implemented PGO in the Rust compiler. The feature is available since Rust 1.37 [1]. However, so far we have not seen any actual performance gains from enabling PGO for Rust code. Performance even seems to drop 1-3% with PGO enabled. I wonder why that is and I'm hoping that someone here might have experience

On Wed, Feb 25, 2015 at 10:52 AM, Philip Reames <listmail at philipreames.com> wrote: > On 02/24/2015 03:31 PM, Diego Novillo wrote: > > > We (Google) have started to look more closely at the profiling > infrastructure in LLVM. Internally, we have a large dependency on PGO to get > peak performance in generated code. > > Some of the dependencies we have on profiling

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