[LLVMdev] IC profiling infrastructure

[Justin Bogner]

"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 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 hash checking verifies if the counter
> assigned regions in the source has been changed across profile consumption
> runs.

This isn't a good reason to keep value_kind - the function hash not
reflecting these kinds of changes is a problem regardless of whether or
not we have multiple types. We should just add hash computations for
these indirect call counters. As long as we only add this when indirect
profiling is turned on it won't invalidate old hashes so it's trivial to
stay backwards compatible.

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.