<div dir="ltr"><slightly off topic><div>Indirect Call Target Profiling can be used for other purposes as well, for example to provide feedback to fuzzers. </div><div>I've recently committed a very simple patch to AddressSanitizer that adds indirect call instrumentation specifically for this purpose. </div><div>(llvm part: <a href="http://llvm.org/viewvc/llvm-project?rev=220699&view=rev" target="_blank" style="font-family:arial,sans-serif;font-size:13px">http://llvm.org/viewvc/llvm-project?rev=220699&view=rev</a>, compiler-rt part coming soon). </div><div>If this or similar proposal gets implemented in clang I'd love to see two things: </div><div>  - extreme performance of instrumented code (<span style="font-family:arial,sans-serif;font-size:13px">instrument_indirect_call_site needs to be very fast, lock-free and, ideally contention-free)</span></div><div>  - command-line utility that can dump the indir call coverage data in human- and scrip- readable format. <br><div></slightly off topic><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 30, 2014 at 11:28 AM,  <span dir="ltr"><<a href="mailto:betulb@codeaurora.org" target="_blank">betulb@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
We've been working on adding indirect call target profiling support to the<br>
instrumented profiler for PGO purposes. I’d like to propose the following<br>
design.<br>
<br>
Goal: Our aim is to add instrumentation around indirect call sites, so<br>
that the run-time can track the callee addresses and their access<br>
frequencies. From the addresses we’d like to infer the callee names and<br>
use it in optimizations to improve the performance of applications which<br>
make heavy use of indirect calls. Spec is a candidate benchmark that gives<br>
us applications both written in C and C++ and makes use of indirect calls.<br>
Spec can prove the effectiveness of optimizations making use of this<br>
additional data.<br>
<br>
Design:<br>
To determine the function names from the profiled target addresses, we've<br>
extended the data variable that is built by build_data_var() in<br>
CodeGenPGO.cpp (abbr. PFDV: Per Function Data Variable) to save the<br>
function addresses. PFDV is communicated to the run-time during function<br>
registration and outputted in the raw profile data file. This data<br>
structure is also extended to contain the number of indirect call sites<br>
for each function.<br>
<br>
To help communicate the target addresses to run-time, we insert a call to<br>
a run-time routine before each indirect call site in clang. Something<br>
like:<br>
<br>
void instrument_indirect_call_site(uint8_t *TargetAddress, void *Data,<br>
uint32_t CounterIndex);<br>
<br>
This run-time function takes in the target address, the index/id of the<br>
indirect call site and the pointer to the profile data variable of the<br>
caller (i.e. PFDV). The runtime routine checks if the target address has<br>
been seen before for the indirect call site index/id or not. If not, then<br>
an entry is added into an internal data structure. If yes, the counter<br>
associated with the target address is incremented by 1. This counter<br>
records the number of times the target address is called.<br>
<br>
Raw profile data file stores the target addresses and the number of times<br>
any target address is taken per each call site index. llvm-profdata reads<br>
the function addresses from the raw profile data file, then compares them<br>
against the target addresses from the same file. Each match helps identify<br>
the function names for the recorded addresses.<br>
<br>
llvm-profdata processed files contain the target function names. In case<br>
no function matches the target address then the target address is<br>
converted to string and stored in that format in the “indexed” data files.<br>
On the PGO path, clang consumes the returned indirect target data and<br>
attaches the following metadata at the indirect call sites.<br>
<br>
!33 = metadata !{metadata !"indirect_call_targets", i64<br>
<total_exec_count>, metadata !"target_fn1”, i64 <target_fn1_count>,<br>
metadata !"target_fn2”, i64 <target_fn2_count>, ….}<br>
<br>
Only the top most called N function names are recorded at each indirect<br>
call site. “indirect_call_targets” is the string literal identifying the<br>
fields of this metadata. <total_exec_count> is a 64 bit value for the<br>
total number of times the indirect call is executed followed by the<br>
function names and execution counts of each target.<br>
<br>
We're working on collecting further data points on the overhead of this<br>
additional instrumentation on the original profiler. Looking forward to<br>
hearing your comments.<br>
<br>
Thanks,<br>
-Betul Buyukkurt<br>
<br>
Qualcomm Innovation Center, Inc.<br>
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,<br>
a Linux Foundation Collaborative Project<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div>