[LLVMdev] IC profiling infrastructure

[Xinliang David Li]

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:
>> But since the consumer is the frontend, and it knows which counts are
>> which, it knows the kind, no? I don't understand how storing the kind
>> info helps or hurts - it's just redundant.
>
> Yes, the frontend consumer knows, but the raw reader does not. It is
> natural to do those processing when processing the raw profile data
> (for instance when function pointer to name mapping still exists).
>
>>
>>>>
>>>> The other thing we should do is store which profiling options are
>>>> enabled, in both formats. When we specify profile-instr-use it'll be
>>>> less error prone if we can detect whether or not this includes indirect
>>>> call profiling without checking other options, and it's probably a good
>>>> idea for "llvm-profdata merge" to disallow merging profiles that are
>>>> gathering different sets of data. A bitfield seems suitable for this.
>>>
>>> For value profiling, allowing profile-gen and profile-use passes using
>>> different options is a useful feature. Consider the following
>>> scenarios:
>>> 1) collect the same profile data once with all kinds of value profile
>>>    data collected. The exact same profile data can be used in performance
>>>    experiments with different kinds of value profiling enabled/disabled
>>
>> This use case is pretty easy to accomodate for with the model where the
>> profile stores its type. We could autodetect the type to decide how to
>> interpret the profile, and if more specific profile flags are set simply
>> ignore some of the data. The thing that the file format storing the type
>> gives us is that it's harder to misinterpret the data by supplying the
>> mismatching flags between reading and writing.
>
> Yes, this is achievable with some extra effort -- for instance by
> collecting the profile sites of all kinds regardless of the flags.
> After profiling matching, simply drop selected sites according to the
> flags.
>
> This adds complexity of the code. With value kinds encoded in profile
> data, the handling is much simpler -- each value profiler only needs
> to deal with its own kind.
>
>>
>>> 2) work around profile-use/value transformation bug selectively for
>>>    some file without the need to change anything in instrumentation pass
>>
>> I'm not sure I understand what you mean here.
>
> Similar to the above, but for correctness.
>
>>
>>> Besides, with the latest patch, the value_kind is not recorded in each
>>> profile value thus the overhead is minimized.
>>
>> The overhead is low, sure, but the code complexity of dealing with the
>> multiple kinds in this way is quite real.
>
> I actually believe having value-kind can help reduce code complexity
> instead of the other way around. What is the extra complexity?
>
> thanks,
>
> David
>
>
>>Since I'm not convinced we're
>> getting real benefit from storing the kind, I don't believe this
>> trade-off is worth it.
>>
>>> thanks,
>>>
>>> David