similar to: Reining in profile instrumentation

> On Dec 13, 2016, at 3:46 AM, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > When either ‘-pg’ or ‘-finstrument-functions’ is used, the compiler inserts the appropriate profiling hooks. This happens prior to inlining, so the hooks remain in place. Have you tried compiling with -fprofile-generate? It enables IR-based profiling instrumentation, which

Thanks Vedant, and my apologies for the delay getting back to you - work got "busy". I wasn't aware of the '-fprofile-generate' option, so thanks for point this out. I have tried running it and I can see the instrumentation hooks that it generates - I assume that there is a library I have to implement to support this, can you let me know where the source for this library

On Fri, Jun 24, 2016 at 1:44 AM Eric Christopher via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Jun 2, 2016, 6:41 PM Xinliang David Li via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> Sounds fine to me, though I am not a fan of using unstable in the option. >> I think a more meaningful way (that capture the essence of the

On Mon, Jun 27, 2016 at 2:53 PM Xinliang David Li <davidxl at google.com> wrote: > There is some misunderstanding about the intention of this flag. The > purpose of the flag is not to turn on profile instrumentation (which > already has -fprofile-instr-generate or -fprofile-generate for it), but to > select which instrumentors to use for PGO (IR or FE). I prefer fewer flags

There is some misunderstanding about the intention of this flag. The purpose of the flag is not to turn on profile instrumentation (which already has -fprofile-instr-generate or -fprofile-generate for it), but to select which instrumentors to use for PGO (IR or FE). I prefer fewer flags too, but sharing flags for completely different purpose does not seem like the right thing to do. David On

On Sun, Jun 26, 2016 at 10:21 PM, Dean Michael Berris <dberris at google.com> wrote: > > > On Mon, Jun 27, 2016 at 2:53 PM Xinliang David Li <davidxl at google.com> > wrote: > >> There is some misunderstanding about the intention of this flag. The >> purpose of the flag is not to turn on profile instrumentation (which >> already has

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

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

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

I would love to see this kind of order profiling support. Using dtrace to generate function orders is actually really problematic because dtrace made tradeoffs in implementation allowing it to ignore probe execution if the performance impact is too great on the system. This can result in dtrace being non-deterministic which is not ideal for generating optimization data. Additionally if order

On Fri, Jan 18, 2019 at 3:56 PM Manman Ren <manman.ren at gmail.com> wrote: > Some background information first, then a quick summary of what we have > discussed so far! > > Background: Facebook app is one of the biggest iOS apps. Because of this, > we want the instrumentation to be as lightweight as possible in terms of > binary size, profile data size, and runtime

On Fri, Jan 18, 2019 at 9:10 PM Manman Ren <manman.ren at gmail.com> wrote: > > > On Fri, Jan 18, 2019 at 4:11 PM Xinliang David Li <davidxl at google.com> > wrote: > >> >> >> On Fri, Jan 18, 2019 at 3:56 PM Manman Ren <manman.ren at gmail.com> wrote: >> >>> Some background information first, then a quick summary of what we have

Thanks for the hint, I didn’t know about this option. That’s a great reference! However, I am trying to be a compiler/language agnostic. Also (for whatever reasons) I need a numeric ID of a function rather then its address. So the question is still opened. May I assume that the following always holds: The first basic block in a function is an entry point and the last basic block in a function is

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

Hi, I'd like to track not just at the function level, but also at the code block level. For example, for a if-else statement, I want to know when the if-branch or else-branch is enter/exit. Is there a clang option similar to -finstrument-functions for code blocks? Alternatively, I could manually insert the code to the IR .ll file. I see the generated .ll use the following function when

Order file is used to teach ld64 how to order the functions in a binary. If we put all functions executed during startup together in the right order, we will greatly reduce the page faults during startup. To generate order file for iOS apps, we usually use dtrace, but some apps have various startup scenarios that we want to capture in the order file. dtrace approach is not easy to automate, it is

Hi everyone, I run some functions using ORC JIT, now I need to add custom instrumentation. I want to add two callbacks to each function: ‘enterFunction' at the beginning and ‘leaveFunction' at the end. Intuition says that I could ‘just' insert CallInst's to the first and the last basic blocks in the function. Am I correct? Are there any other/better way to do this? Is there

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