similar to: [LLVMdev] IC profiling infrastructure

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>

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:

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

"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

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

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,

> 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

> 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

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 frequencies. The acquired data has uses in optimization of indirect function call heavy applications. Our initial findings

On Fri, Jan 15, 2016 at 11:41 AM, Xinliang David Li <davidxl at google.com> wrote: > Tagging profile data with such information is generally useful. My > thoughts are > > 1) such information is probably not needed to be stored in raw format > profile data -- so no runtime changes are needed -- only llvm-profdata > and indexed format need to be enhanced to support this.

We are now very close to push the final stage of the PGO size reduction task. Here is the updated plan going forward: 1) In this round, the format of the indexed profile data won't be unchanged. 2) there will be *no* changes in user interfaces to all profiling related tools including llvm-profdata, llvm-cov -- the change will be transparent in terms of PGO usability. 3) The implementation

There is no further response to this, so I will assume general direction of solution-3 is acceptable ;) Solution-3 can be further improved. Instead of using static symbol table (with zero size __llvm_prf_nm symbols) to store function names for profile display and coverage mapping, the function names can be stored compressed in a non-allocatable section. The compression ratio for function name

On Fri, Sep 4, 2015 at 5:21 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Fri, Sep 4, 2015 at 3:57 PM, Xinliang David Li <davidxl at google.com> > wrote: >> >> > >> > I think it is reasonable to simply replace the key we currently use with >> > MD5(key) for getting a size reduction. In practice for my use cases, I >> >

+ 1 to Sean's suggestion of using a wrapper script to call profdata merge. David, does that work for your use case? Some inline comments --- > On Feb 28, 2016, at 10:45 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Feb 28, 2016, at 12:46 AM, Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >>

On Sat, Feb 27, 2016 at 6:50 PM, Sean Silva <chisophugis at gmail.com> wrote: > I have thought about this issue too, in the context of games. We may want > to turn profiling only for certain frames (essentially, this is many small > profile runs). > > However, I have not seen it demonstrated that this kind of refined data > collection will actually improve PGO results in

On Fri, Oct 9, 2015 at 3:58 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Wed, Oct 7, 2015 at 11:12 PM, Xinliang David Li <davidxl at google.com> > wrote: >> >> There is no further response to this, so I will assume general >> direction of solution-3 is acceptable ;) > No response does not mean "LGTM". > What I meant is that

I have thought about this issue too, in the context of games. We may want to turn profiling only for certain frames (essentially, this is many small profile runs). However, I have not seen it demonstrated that this kind of refined data collection will actually improve PGO results in practice. The evidence I do have though is that IIRC Apple have found that almost all of the benefits of PGO for

On Fri, Sep 4, 2015 at 9:11 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Fri, Sep 4, 2015 at 5:42 PM, Xinliang David Li <davidxl at google.com> > wrote: >> >> On Fri, Sep 4, 2015 at 5:21 PM, Sean Silva <chisophugis at gmail.com> wrote: >> > >> > >> > On Fri, Sep 4, 2015 at 3:57 PM, Xinliang David Li <davidxl at

One of the main missing features in Clang/LLVM profile runtime is the lack of support for online/in-process profile merging support. Profile data collected for different workloads for the same executable binary need to be collected and merged later by the offline post-processing tool. This limitation makes it hard to handle cases where the instrumented binary needs to be run with large number of

Hi David, This is wonderful data and demonstrates the viability of this feature. I think this has alleviated the concerns regarding file locking. As far as the implementation of the feature, I think we will probably want the following incremental steps: a) implement the core merging logic and add to buffer API a primitive for merging two buffers b) implement the file system glue to extend this