similar to: PGO in jit

Hi David, Thanks for your reply. I find that I need to add some new types of profile data that are specific to JIT environment like Function Ordering. Function Ordering is similar to dynamic call graph which records the execution of functions at runtime along with the order in which they are called. Eg: Suppose they are 5 functions (F1..F5). F1 calls other functions in the order described

Hi all, I need to do dynamic profiling in ORC JIT between the runs. Is it possible to re-use parts of the static pgo code in llvm for the purpose given that JIT uses llvm codegen. Or I need to write my own implementation to support profile guide optimization in JIT ? Please tell me if you want information. -- Have a great day! PreeJackie -------------- next part -------------- An HTML

preejackie via llvm-dev <llvm-dev at lists.llvm.org> writes: > Are you suggesting that static analysis is much inferior than > profiling in finding "next executing function" ? I'm stuck at > deciding which one to prefer & implement during this summer project, > Could you please help me? I suspect this is highly code-dependent. For example, it's probably

Dario Domizioli <dario.domizioli at gmail.com> writes: > Hi Diego, > > thanks for clarifying the difference between the two formats. I have noticed > the new note in the "Sample Profile Format" section of the Clang guide > clarifying that it is different from the coverage format. > > So, my further question is... Am I right in understanding that both formats

Hi Diego, thanks for clarifying the difference between the two formats. I have noticed the new note in the "Sample Profile Format" section of the Clang guide clarifying that it is different from the coverage format. So, my further question is... Am I right in understanding that both formats can be used for PGO purposes then? I have tried the following, as in the Clang user guide: $

We collected more data to address some of the questions from the reviewers. Note this time we use clang itself as the benchmark. We choose clang because we think it's a typical C++ program and the reviewers here have good knowledge of the code base. What we measure is running time for clang to compile a large preprocessed source file (4.98M lines of .ii file), using different compilation

Hi, I have a question regarding PGO. I collected profile data with the instrumentation build (-fprofile-instr-generate) and provided for PGO optimization in the second build (with -fprofile-instr-use=xxx.profdata). This works fine. Then I tried to provide the profile data to opt using the option -pgo-instr-use, but this causes an error with the message: "Not an IR level instrumentation

Justin, Sean and other people interested in this proposal, I'm wondering if you have chances to read the new experiment results in my last email sent 2 weeks ago. Can you share you thoughts, or you have other tests that you want to to run? I'm in the final stage of preparing the patch. If you are OK, I can sent out the patch soon. Thanks, -Rong On Wed, Aug 19, 2015 at 5:18 PM, Philip

On Tue, Sep 1, 2015 at 2:32 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Tue, Sep 1, 2015 at 2:10 PM, Xinliang David Li <davidxl at google.com> > wrote: >> >> This is a late reply -- the email somehow skipped my inbox. >> >> > Philip and Sanjoy, out of curiosity do you guys use your own >> > instrumentation >> >

Hi All, I've listed the current topics of interest below, along with some notes on each. We only have 30 minutes so we'll barely scratch the surface of these during the BoF itself. My main aims are for you to meet each other, identify potential areas of collaboration, identify things that I can do to unblock you, and get the ball rolling on some conversations that we can continue on the

Hi, David: Good point, it will be interesting to see speculative compilation in this context applying on devirtualization, with high level (type) information if applicable. > On Mar 28, 2019, at 2:35 PM, preejackie <praveenvelliengiri at gmail.com> wrote: > > Hi David & Bekket, > > Thanks your replies :) > > David, Indent here is: ORC v2 JIT APIs has

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

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

Hi Bekket, Thank you for your reply. Earlier I came across a paper called "Dynamic Look Ahead Compilation: Hide JIT compilation latencies", it devised some methods for JIT compilation of functions before the actual call takes place by using call graph analysis, branch probabilities to generate a list of functions with high likelihood of execution in near future. In my opinion it

One aspect of this that I have not seen discussed is that middle-end instrumentation enables PGO optimizations to front-ends other than Clang. While I agree that FE instrumentation could be improved, it still requires every FE to implement essentially the same common functionality. Having PGO instrumentation generated in the middle-end, allows us every FE to automatically take advantage of PGO.

Hello, I have a question regarding PGO instrumented BBs (I use IR-level instrumentation). It seems that instrumented BBs do not match between the two compilations for profile-gen and profile-use for some cases. Here is an example from SPECcpu 2006 lbm (a simple case consisting of just two modules). In the first compilation, we have 5 instrumentation points for the main function as follows: $

Thanks for the thoughtful questions, David. See my answers inline. Thanks, Wenlei From: Xinliang David Li <davidxl at google.com> Date: Friday, August 7, 2020 at 1:24 PM To: Wenlei He <wenlei at fb.com> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, Wei Mi <wmi at google.com>, Hongtao Yu <hoy at fb.com> Subject: Re: [RFC] Context-sensitive

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

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