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

[Xinliang David Li via llvm-commits]

On Tue, Jan 24, 2017 at 10:49 AM, Rong Xu <xur at google.com> wrote:

>
>
> On Mon, Jan 23, 2017 at 10:22 AM, David Li via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
>> davidxl added a comment.
>>
>> A general comment.
>>
>> The range profiling should not be limited to just memory intrinsics.  It
>> should be designed to be a more general interval profiler. Interval
>> profiler is also useful for other value profiling transformations such as
>> mod operation for integer values (x%y). The value profiler can do interval
>> profiling for division x/y and track resulting values in interval [0, 1].
>>
>
> why do we need to track the result? I think usually we profile the
> divisor. Current code can track the range of divisor. The only issue is
> that I assume the type to be unsigned.
>

There are two types of value profiling related to div/mod. The one I
mentioned is for 'mod' operation:

if the value of x/y is mostly 0,

x%y can be transformed into

 if (x < y)
    return x;
 ..

if 1 is also one of the hot target value of x/y, x%y can be transformed like
  if (y > x - y)
     return x-y;

In other words, we only care about values in range [0,1].



>
>
>> In a more general form, an interval profiler API should specify the
>> following things
>>
>> 1. counter index
>> 2. interval start and end (inclusive) : [S, E]
>> 3. optionally specify the start value of a large value range [SL, inf)
>>
>> 3 + (E-S+1)  values will be tracked:
>> (-inf, S) one value
>> [S,E] one for each in the range
>> [E, SL) one value
>> [SL, inf) for one.
>>
>> The client (instrumentor) decides the the interval boundaries depending
>> on the value profile kind.
>>
>>
> Index is obtained incrementally in the instrumentation. I don't think it's
> necessary to expose it to the API.
> right now, there is options to control the intervals. it's universal to
> all range profiles.
> I can have the client choose the intervals by including it into the
> instrumentation intrinsic.
>
>
See my later comments about eliminating this change.

David

>
>
>>
>> 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/0c3585ed/attachment.html>