[PATCH] Indirect call target profiling compiler-rt changes

[Betul Buyukkurt]

> What I meant in the review is that the source comment above this
> change also needs to be updated to match.

I'll check the source comment and address any other concerns in my
upcoming patches. Thanks for the notice.

> On Wed, May 13, 2015 at 11:08 AM, Betul Buyukkurt <betulb at codeaurora.org>
> wrote:
>> Instrumentation based profile readers depend on the magic field check to
>> decide which reader class to instantiate.
>
> How about FormatVersion? What is the convention here (using
> FormatVersion vs Magic string)?

FormatVersion is not checked against currently as there has only been a
single version for the raw reader. I'm not sure if there is a
"convention".

Depending on the format version - in my opinion - would further complicate
the already complex reader implementation. Deriving a new class out of the
current RawInstrProfReader class seemed more modular in terms of reading
in the value profiling data.

>> To allow the reading of the new profile data output (extended w/ value
>> profile entries) with a different reader class, the magic field has been
>> updated from lprof(r/R) to vprof(r/R).
>
> I suppose this is related to your new profiler reader patch.    What
> do you mean by allowing reading of extended value profile data with a
> different reader class?  A different reader class means the old reader
> ?

template <class IntPtrT>
class RawInstrValueProfReader : public RawInstrProfReader<IntPtrT> {...}

The derived class is reusing the data structures and some of the
ProfileData reading from the parent class.

-Betul

>
> David
>
>>
>>
>> http://reviews.llvm.org/D9009
>>
>> EMAIL PREFERENCES
>>   http://reviews.llvm.org/settings/panel/emailpreferences/
>>
>>
>