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

[Xinliang David Li via llvm-commits]

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


> (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/28558ed6/attachment.html>