search for: value_kind

...gt;>> implicitly, much like it knows the difference between a counter for an >>>> "if" and a "for" apart implicitly. Just store one set of profiling data >>>> and let the frontend sort it out. >>> >>> I think so too. However, value_kind should stay around until the kinds of >>> expressions whose values are computed are included in the hash >>> computation. Otherwise, if a value-profiled expression is to be removed >>> from source, then all the rest of the values would get attached to the MD >>>...

...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 set of profiling data >> and let the frontend sort it out. > > I think so too. However, value_kind should stay around until the kinds of > expressions whose values are computed are included in the hash > computation. Otherwise, if a value-profiled expression is to be removed > from source, then all the rest of the values would get attached to the MD > fields of wrong types. Currently...

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

> 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 stored intermixed. That is about it. >> More re...

...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> wrote: > Any decision on below? Is everyone OK w/ removing the value_kind and > keeping > the raw profile writer and reader code to do exactly what we need it to do > today. Justin, if you agree, I'll make/upload the changes to right away? > > Thanks, > -Betul > -----Original Message----- > From: Betul Buyukkurt [mailto:betulb at codeaurora.or...

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

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,