[PATCH] D28964: [PGO] Value profile support for value ranges

[Xinliang David Li via llvm-commits]

On Tue, Jan 24, 2017 at 11:02 AM, Xinliang David Li <davidxl at google.com>
wrote:

>
>
> On Tue, Jan 24, 2017 at 10:57 AM, Rong Xu <xur at google.com> wrote:
>
>> Yes. that's another way to do this. I considered that when I implemented
>> the code. I choose not do because:
>> (1) it makes it the instrumentation code complex and increase the code
>> size as basically you inline the logic to every instrumentation site.
>>
>
> We can filter a lot of memcpy sites with constant sizes, so the number of
> sites remaining should not be large (compared to virtual calls).
>


To avoid code size bloat in instrumentation,  it is possible to introduce a
wrapper API in compiler_rt which takes more parameters (defininig interval
boundaries). The wrapper API does this
1) collapse the target value according to the interval definitition
parameters
2) call into __llvm_profile_instrument_target directly.

The instrumentation lowerer can call the wrapper API directly.

David



>
>
>> (2) it affects the static counter allocation. This range profile
>> potentially uses a lot more counters that current indirectly calls.
>>
>
> Why is that?
>
> David
>
>
>
>
>> The advantage of not change compiler_rt is that less information is
>> needed to pass b/w runtime and instrumentation. This especially true is we
>> want to have profile client to control it's own ranges.
>>
>> But I still think the change in compiler_rt is straight-forward way.
>>
>> On Tue, Jan 24, 2017 at 10:33 AM, David Li via Phabricator <
>> reviews at reviews.llvm.org> wrote:
>>
>>> davidxl added a comment.
>>>
>>> In fact, I don't there is a need for compiler_rt change at all for the
>>> interval/range profiling. The compiler_rt API should be kept simple.  In
>>> other words, interval profiling should already be 'lowered' into regular
>>> value profiling in the instrumentation lowering phase. The instrumentation
>>> lowering will general inline sequence that collapse ranges into single
>>> value depending on the value profile kind.  Only the
>>> __llvm_profile_instrument_target low level interface is needed.
>>>
>>> The only downside of this approach that we can not override the range
>>> definitions at runtime -- but I don't think that is worth the complexity
>>> introduced.
>>>
>>>
>>> Repository:
>>>   rL LLVM
>>>
>>> https://reviews.llvm.org/D28964
>>>
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170124/ce51f3c4/attachment.html>