llvm dev - Nov 2014 - [LLVMdev] Indirect call site profiling

> On 10/24/2014 05:26 PM, betulb at codeaurora.org wrote:
>> Hi All,
>>
>> We've been working on enhancing LLVM's instrumentation based
profiling
>> by
>> adding indirect call target profiling support. Our goal is to add
>> instrumentation around indirect call sites, so that we may track the
>> frequently taken target addresses and their call frequencies.
> Just to make sure I understand what're you describing, you're doing
> value profiling specifically for the target address of an indirect call
> through a function pointer right?
We're recording the called values at the indirect call sites. This in
essence can be considered as a type of value profiling.
>> The acquired data has uses in optimization of indirect function call
>> heavy applications. Our initial findings show that using the profile
>> data
>> in optimizations would help improve the performance of some of the spec
>> benchmarks notably. We have a proof of concept implementation,  which
we
>> plan to put it up for review. However, I’d like to inquire prior if
>> there
>> are any plans or ongoing work done in the community to enable indirect
>> call target profiling support or not. Please inform if cfe-dev is a
>> better
>> candidate for posting PGO related emails.
> I'll be interested in seeing your work.  I'm interested in
techniques
> for guarded devirtualization, but the profiling infrastructure should be
> fairly common.  If we could arrange the instrumentation in such a way to
> enable both use cases, we could share infrastructure.
Thanks, we've recently posted an RFC on the design. The design is quite
straightforward and simple but the gains will be seen when the data is
used in optimizations.
> Philip
>>
>> Thanks,
>> -Betul Buyukkurt
>>
>> Employee of the Qualcomm Innovation Center, Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux
>> Foundation Collaborative Project
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

On 11/03/14 12:12, betulb at codeaurora.org wrote:
>
>> I'll be interested in seeing your work.  I'm interested in
techniques
>> for guarded devirtualization, but the profiling infrastructure should
be
>> fairly common.  If we could arrange the instrumentation in such a way
to
>> enable both use cases, we could share infrastructure.
> Thanks, we've recently posted an RFC on the design. The design is quite
> straightforward and simple but the gains will be seen when the data is
> used in optimizations.
A note on the profile. The sample pgo profiler tracks indirect function 
calls via sampling at the call sites. Currently this data is not being 
used in optimizations, but it's captured in the sample profiles 
(lib/Transforms/Scalar/SampleProfile.cpp).


Diego.

On 11/03/2014 09:21 AM, Diego Novillo wrote:
>
> On 11/03/14 12:12, betulb at codeaurora.org wrote:
>>
>>> I'll be interested in seeing your work. I'm interested in
techniques
>>> for guarded devirtualization, but the profiling infrastructure 
>>> should be
>>> fairly common.  If we could arrange the instrumentation in such a 
>>> way to
>>> enable both use cases, we could share infrastructure.
>> Thanks, we've recently posted an RFC on the design. The design is
quite
>> straightforward and simple but the gains will be seen when the data is
>> used in optimizations.
>
> A note on the profile. The sample pgo profiler tracks indirect 
> function calls via sampling at the call sites. Currently this data is 
> not being used in optimizations, but it's captured in the sample 
> profiles (lib/Transforms/Scalar/SampleProfile.cpp).
We also have a custom profiling mechanism which collects similar data.  
It seems like moving forward with a common metadata format to exploit 
this would be interesting.

(I'm moving the rest of my comments to the proposal thread; I wanted 
this one in context.)

Philip