search for: md_prof

...g David Li <davidxl at google.com> >> wrote: >> >>> Diego and I have discussed this according to the feedback received. We >>> have revised plan for this (see Diego's last reply). Here is a more >>> detailed re-cap: >>> >>> 1) keep MD_prof definition as it is today; also keep using the >>> frequency propagation as it is (assuming programs with irreducible >>> loops are not common and not important. If it turns out to be >>> otherwise, we will revisit this). >>> 2) fix all problems that lead to wron...

...e sense to me: On Tue, Mar 24, 2015 at 10:27 AM, Xinliang David Li <davidxl at google.com> wrote: > Diego and I have discussed this according to the feedback received. We > have revised plan for this (see Diego's last reply). Here is a more > detailed re-cap: > > 1) keep MD_prof definition as it is today; also keep using the > frequency propagation as it is (assuming programs with irreducible > loops are not common and not important. If it turns out to be > otherwise, we will revisit this). > 2) fix all problems that lead to wrong 'frequency/count' comp...

...information in LLVM IR. It is great to have two complementary > approaches to collecting profile data, but two representations in > the IR would not make sense. > > > Yeah, I don't think I'll continue to push for a new MD_count > attribute. If we were to make MD_prof be a "real" execution count, > that would be enough. Note that by re-using MD_prof we are not > changing its meaning at all. The execution count is still a weight and > the ratio is still branch probability. All that we are changing are > the absolute values of the number...

> On Mar 24, 2015, at 10:27 AM, Xinliang David Li <davidxl at google.com> wrote: > > Diego and I have discussed this according to the feedback received. We > have revised plan for this (see Diego's last reply). Here is a more > detailed re-cap: > > 1) keep MD_prof definition as it is today; also keep using the > frequency propagation as it is (assuming programs with irreducible > loops are not common and not important. If it turns out to be > otherwise, we will revisit this). > 2) fix all problems that lead to wrong 'frequency/count' comp...

...; wrote: >>>> >>>>> Diego and I have discussed this according to the feedback received. We >>>>> have revised plan for this (see Diego's last reply). Here is a more >>>>> detailed re-cap: >>>>> >>>>> 1) keep MD_prof definition as it is today; also keep using the >>>>> frequency propagation as it is (assuming programs with irreducible >>>>> loops are not common and not important. If it turns out to be >>>>> otherwise, we will revisit this). >>>>> 2) fi...

> On Mar 2, 2015, at 4:19 PM, Diego Novillo <dnovillo at google.com> wrote: > > On Thu, Feb 26, 2015 at 6:54 PM, Diego Novillo <dnovillo at google.com <mailto:dnovillo at google.com>> wrote: > > I've created a few bugzilla issues with details of some of the things I'll be looking into. I'm not yet done wordsmithing the overall design document.

...your plan of attack and reserve discussion on llvm-dev for > things that are being proposed semi near term. Just my 2 cents. > > This is a summary of the main changes we are looking at: > > Need to faithfully represent the execution count taken from dynamic > profiles. Currently, MD_prof does not really represent an execution count. > This makes things like comparing hotness across functions hard or > impossible. We need a concept of global hotness. > > What does MD_prof actually represent when used from Clang? I know I've been > using it for execution counters...

...sentation, 64 bit is needed. The branch weight >> here is different and does not needs to be 64bit to represent branch >> probability precisely. > > > Actually, the branch weights are really counts. No -- I think that is our original proposal (including changing the meaning of MD_prof meta data) :). After many rounds of discussions, I think what we eventually settled to is to 1) use 64 bit value to represent function entry count 2) keep branch weight representation and meaning as it is Changing weights to 64bit for can slightly increase memory usage. In fact, what we want long...

...; wrote: >>>> >>>>> Diego and I have discussed this according to the feedback received. We >>>>> have revised plan for this (see Diego's last reply). Here is a more >>>>> detailed re-cap: >>>>> >>>>> 1) keep MD_prof definition as it is today; also keep using the >>>>> frequency propagation as it is (assuming programs with irreducible >>>>> loops are not common and not important. If it turns out to be >>>>> otherwise, we will revisit this). >>>>> 2) fi...

...e major issues that we'd like to address. The document is a bit on the lengthy side, so it may be easier to start with an email discussion. This is a summary of the main changes we are looking at: 1. Need to faithfully represent the execution count taken from dynamic profiles. Currently, MD_prof does not really represent an execution count. This makes things like comparing hotness across functions hard or impossible. We need a concept of global hotness. 2. When the CFG or callgraph change, there need to exist an API for incrementally updating/scaling counts. For instance, when...

...be the major issues that we'd like to address. The document is a bit on the lengthy side, so it may be easier to start with an email discussion. This is a summary of the main changes we are looking at: > Need to faithfully represent the execution count taken from dynamic profiles. Currently, MD_prof does not really represent an execution count. This makes things like comparing hotness across functions hard or impossible. We need a concept of global hotness. The plan that we have discussed in the past (I don’t remember when) was to record simple function entry execution counts. Those could be...

...lobal hotness. Profile (execution) > count fits the bill > 2) There are two ways to compute profile count for BBs > a) directly compute it from the edge count recorded in profile data > (and BB Frequency can be directly scaled from it), but this change > requires slightly changing MD_prof's meaning or introducing MD_count > to record edge count without capping/scaling. > > b) Just recording the entry profile count (minimal change), but do > not change MD_prof. This approach will reuse block frequency > propagation, but the later relies on unaltered branch >...

...>> count fits the bill >>> 2) There are two ways to compute profile count for BBs >>> a) directly compute it from the edge count recorded in profile data >>> (and BB Frequency can be directly scaled from it), but this change >>> requires slightly changing MD_prof's meaning or introducing MD_count >>> to record edge count without capping/scaling. >>> >>> b) Just recording the entry profile count (minimal change), but do >>> not change MD_prof. This approach will reuse block frequency >>> propagation, but the...

...ing it it requires more > memory as well as incremental update interfaces. Many transformation > passes simply skip it and directly access the meta data in IR. > Can you be more specific? BPI and BFI are used in *many* places, and on an initial inspection almost everywhere that accesses MD_prof directly appears to do so in order to *set* or *update* the profile information without doing detailed analysis on it. Which seems fine with my outline of the invariants? > >> Now, the original design only accounted for profile information *within* >> a function body, clearly it ne...

> On Mar 24, 2015, at 3:22 PM, Xinliang David Li <davidxl at google.com> wrote: > > On Tue, Mar 24, 2015 at 2:47 PM, Bob Wilson <bob.wilson at apple.com <mailto:bob.wilson at apple.com>> wrote: >> >>> On Mar 24, 2015, at 12:08 PM, Xinliang David Li <davidxl at google.com> wrote: >>> >>> On Tue, Mar 24, 2015 at 10:54 AM, Bob

...your plan of attack and reserve discussion on llvm-dev for > things that are being proposed semi near term. Just my 2 cents. > > This is a summary of the main changes we are looking at: > > Need to faithfully represent the execution count taken from dynamic > profiles. Currently, MD_prof does not really represent an execution count. > This makes things like comparing hotness across functions hard or > impossible. We need a concept of global hotness. > > What does MD_prof actually represent when used from Clang? I know I've been > using it for execution counters...

...> count fits the bill > >> 2) There are two ways to compute profile count for BBs > >> a) directly compute it from the edge count recorded in profile data > >> (and BB Frequency can be directly scaled from it), but this change > >> requires slightly changing MD_prof's meaning or introducing MD_count > >> to record edge count without capping/scaling. > >> > >> b) Just recording the entry profile count (minimal change), but do > >> not change MD_prof. This approach will reuse block frequency > >> propagation, bu...

yes -- for count representation, 64 bit is needed. The branch weight here is different and does not needs to be 64bit to represent branch probability precisely. David On Fri, Apr 24, 2015 at 12:21 PM, Smith, Kevin B <kevin.b.smith at intel.com> wrote: > FWIW. Intel compiler's profile instrumentation uses 64 bit integer counters. > We wrestled with similar problems for a long

...39;d like to address. The document is a bit on the lengthy side, so it > may be easier to start with an email discussion. This is a summary of the > main changes we are looking at: > > 1. Need to faithfully represent the execution count taken from dynamic > profiles. Currently, MD_prof does not really represent an execution > count. This makes things like comparing hotness across functions hard or > impossible. We need a concept of global hotness. > 2. When the CFG or callgraph change, there need to exist an API for > incrementally updating/scaling counts....

On Mon, Apr 18, 2016 at 2:48 PM Hal Finkel <hfinkel at anl.gov> wrote: > > > ------------------------------ > > *From: *"Xinliang David Li" <davidxl at google.com> > > On Mon, Apr 18, 2016 at 2:33 PM, Mehdi Amini <mehdi.amini at apple.com> > wrote: >> >> In the current case at stake: the issue is that we can't make the >>