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

[Rong Xu via llvm-commits]

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.
(2) it affects the static counter allocation. This range profile
potentially uses a lot more counters that current indirectly calls.

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