similar to: [LLVMdev] Indirect call site profiling

> On 10/24/2014 05:26 PM, betulb at codeaurora.org wrote: >> Hi All, >> >> We've been working on enhancing LLVM's instrumentation based profiling >> by >> adding indirect call target profiling support. Our goal is to add >> instrumentation around indirect call sites, so that we may track the >> frequently taken target addresses and their call

> On 10/24/14, 8:26 PM, betulb at codeaurora.org wrote: >> Hi All, >> >> We've been working on enhancing LLVM's instrumentation based profiling >> by >> adding indirect call target profiling support. Our goal is to add >> instrumentation around indirect call sites, so that we may track the >> frequently taken target addresses and their call

> Xinliang David Li <davidxl at google.com> writes: >>> From: <betulb at codeaurora.org> >>> Date: Tue, Apr 7, 2015 at 12:44 PM >>> Subject: [LLVMdev] IC profiling infrastructure >>> To: llvmdev at cs.uiuc.edu >>> >>> >>> >>> Hi All, >>> >>> We had sent out an RFC in October on indirect call

Hi Betul, I've finally gotten around to going over this in detail - sorry for the delay, and thanks for working on this. I think that the general approach is a good one, and that this will end up working well. I have a couple of points on a high level, and I'll also send some review for the patches you've sent out. - The raw profile format does not need to be backwards compatible,

> From: <betulb at codeaurora.org> > Date: Tue, Apr 7, 2015 at 12:44 PM > Subject: [LLVMdev] IC profiling infrastructure > To: llvmdev at cs.uiuc.edu > > > > Hi All, > > We had sent out an RFC in October on indirect call target profiling. The > proposal was about profiling target addresses seen at indirect call sites. > Using the profile data we're

"Betul Buyukkurt" <betulb at codeaurora.org> writes: >> - We don't need to store the value profiling kind in the data at all. >> The frontend knows which invocations of the intrinsic are for each kind >> implicitly, much like it knows the difference between a counter for an >> "if" and a "for" apart implicitly. Just store one

My suggestion: 1. Keep the value kind enum, but remove the reserved kinds 2. In compiler-rt code, assert the kind to be icalltarget and remove the loop 3. Keep the indexed format (as is now) 4. Add assertion in profile use that icalltarget is the only expected kind. Justin, does this sound reasonable? David On Jul 2, 2015 1:10 PM, "Betul Buyukkurt" <betulb at codeaurora.org>

> Xinliang David Li <davidxl at google.com> writes: >> Justin, thanks for the reply. >> I would like to point out that value_kind is actually not really stored in the raw profile data (nor do we intend to do so), other than the minimal information about per value kind NumOfSites info in per-function profile header. Basically the data is organized per value kind instead of

Xinliang David Li <davidxl at google.com> writes: > On Mon, Jun 15, 2015 at 5:35 PM, Justin Bogner <mail at justinbogner.com> wrote: >> "Betul Buyukkurt" <betulb at codeaurora.org> writes: >>>> - We don't need to store the value profiling kind in the data at all. >>>> The frontend knows which invocations of the intrinsic are for

Justin, do you have more concerns on keeping value_kind? If there is still disagreement, can we agree to move on with it for now ? After the initial version of the patches checked in, we can do more serious testings with large apps and revisit this if there are problems discovered. thanks, David On Mon, Jun 15, 2015 at 10:47 PM, Xinliang David Li <davidxl at google.com> wrote:

Hi, we've implemented an indirect call promotion llvm pass. The design notes including examples are shown below. This pass complements the indirect call profile infrastructure http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084271.html Your feedback and comments will be highly appreciated. Thanks, Ivan ============================================================================RFC:

On Wed, Oct 25, 2017 at 09:13:54AM -0700, Xinliang David Li wrote: > On Wed, Oct 25, 2017 at 12:26 AM, Roger Pau Monné via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > Hello, > > > > I've been working on implementing some basic functionality in order to > > use the llvm profiling functionality inside of a kernel (the Xen > > hypervisor).

I think this is the same underlying issue as https://bugs.llvm.org/show_bug.cgi?id=40320. CCing Reid, who's had a bunch of thoughts on this in the past. On 1/11/20, 10:25 AM, "llvm-dev on behalf of Chrulski, Christopher M via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: Hi, I've run into a bug with the LLVM

I think the simplest, most complete, short term fix, would be to call llvm::colorEHFunclets, and to have the relevant instrumentation passes apply the appropriate funclet bundle when inserting function calls. It's not elegant because it means every simple instrumentation pass that inserts regular function calls (ASan, TSan, MSan, instrprof, etc) needs to be funclet-aware. But, it will work,

Hello all, I'm wondering as to the status of control flow profiling in llvm. From what I can gather there was an old system (using opt -insert-edge-profiling and the like) which was removed in this commit llvm.org/viewvc/llvm-project?view=revision&revision=191835 . The commit message mentions "modern PGO efforts", but I can't find anything in the source tree or

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

Justin, thanks for the reply. I would like to point out that value_kind is actually not really stored in the raw profile data (nor do we intend to do so), other than the minimal information about per value kind NumOfSites info in per-function profile header. Basically the data is organized per value kind instead of stored intermixed. That is about it. More replies below. On Mon, Jun 29, 2015

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

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