similar to: PGO is ineffective for Rust - but why?

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

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

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

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

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

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

On Sat, Aug 8, 2015 at 6:31 AM, Xinliang David Li <davidxl at google.com> wrote: > On Fri, Aug 7, 2015 at 10:56 PM, Sean Silva <chisophugis at gmail.com> wrote: > > Accidentally sent to uiuc server. > > > > > > On Fri, Aug 7, 2015 at 10:49 PM, Sean Silva <chisophugis at gmail.com> > wrote: > >> > >> Can you compare your results

Accidentally sent to uiuc server. On Fri, Aug 7, 2015 at 10:49 PM, Sean Silva <chisophugis at gmail.com> wrote: > Can you compare your results with another approach: simply do not > instrument the top 1% hottest functions (by function entry count)? If this > simple approach provides most of the benefits (my measurements on one > codebase I tested show that it would eliminate

Instrumentation based Profile Guided Optimization (PGO) is a compiler technique that leverages important program runtime information, such as precise edge counts and frequent value information, to make frequently executed code run faster. It's proven to be one of the most effective ways to improve program performance. An important design point of PGO is to decide where to place the

Hello David, thanks for detailed response! Do you have any tests that you use to measure the PGO effectiveness? I have tested clang version 6.0 with the same sample that Jie Chen used in 2016 and actually both frontend-based PGO and IR-based make code run slower, see the average time: clang++ -O3: 3.15 sec  clang++ -O3 and -fprofile-instr-use: 3.160 sec clang++ -O3 and -fprofile-use: 3.180 sec

David, could you please clarify on which code did you gain 10% improvement? I have run numerous tests with and w/o this option and it looks like it has no effect on performance (I am talking of the old 2016 sample to be concrete). Maybe we could investigate it together? Just tell me where to start? On 02/07/2018 02:11 AM, Xinliang David Li wrote: > Victor, thanks for the experiment. > >

On Thu, Jun 2, 2016 at 5:30 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Thu, Jun 2, 2016 at 2:51 PM, Frédéric Riss <friss at apple.com> wrote: > >> >> On Jun 2, 2016, at 12:10 AM, Sean Silva <chisophugis at gmail.com> wrote: >> >> >> >> On Wed, Jun 1, 2016 at 5:46 PM, Frédéric Riss <friss at apple.com> wrote:

Victor, thanks for the experiment. My suspicion is it is due to the remaining issues with block layout -- especially with loop rotation (with PGO). Another problem is that tail dup is not happening after loop rotation which can limit the effectiveness of loop rotation. I tried the internal option -mllvm -force-precise-rotation-cost and there is about 10% speedup with -fprofile-use. This option

Victor, please file a bug tracking the issue. We can put relevant information there including test cases used in the experiment etc. thanks, David On Wed, Feb 7, 2018 at 2:15 PM, Victor Leschuk <vleschuk at accesssoftek.com> wrote: > David, could you please clarify on which code did you gain 10% > improvement? I have run numerous tests with and w/o this option and it > looks

> On Jun 2, 2016, at 12:10 AM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Wed, Jun 1, 2016 at 5:46 PM, Frédéric Riss <friss at apple.com <mailto:friss at apple.com>> wrote: > >> On Jun 1, 2016, at 1:46 PM, Sean Silva <chisophugis at gmail.com <mailto:chisophugis at gmail.com>> wrote: >> >> >> >> On

Quick update. I've gotten derailed from posting a patch for this due to focusing on higher priority PGO inlining work. No ETA. -- Sean Silva On Fri, Jun 3, 2016 at 6:06 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Thu, Jun 2, 2016 at 6:41 PM, Xinliang David Li <davidxl at google.com> > wrote: > >> >> >> On Thu, Jun 2, 2016 at 5:30

> On Jun 2, 2016, at 5:30 PM, Sean Silva <chisophugis at gmail.com> wrote: > > This also means that if the consensus is that -fprofile-instr-generate should really change its meaning to mean IRPGO, I’m open to having this internal patch on our side. > > Yeah, it sounds like someone is going to have to keep a "private patch" to change the default. At that point

Hello David! I have recently started acquaintance with PGO in LLVM/clang and found your e-mail thread: http://lists.llvm.org/pipermail/llvm-dev/2016-May/099395.html . Here you posted a nice list of optimizations that use profiling and of those which could be using but don't. However that thread is about 2 years old. Could you please kindly let me know if there were any significant changes in

On Sun, Feb 4, 2018 at 9:59 PM, Victor Leschuk <vleschuk at accesssoftek.com> wrote: > Hello David! > > I have recently started acquaintance with PGO in LLVM/clang and found > your e-mail thread: > http://lists.llvm.org/pipermail/llvm-dev/2016-May/099395.html . Here you > posted a nice list of optimizations that use profiling and of those > which could be using but

> On Jun 1, 2016, at 1:46 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Tue, May 31, 2016 at 6:02 PM, Frédéric Riss <friss at apple.com <mailto:friss at apple.com>> wrote: > >> On May 24, 2016, at 5:21 PM, Sean Silva <chisophugis at gmail.com <mailto:chisophugis at gmail.com>> wrote: >> >> >> >> On