<div dir="ltr">I had some concerns about the profiler, so I did quite a bit of comparison of the the performance of this implementation with a couple of alternatives.<div><br></div><div>The good news is that from the data I collected so far, this implementation looks promising and competitive (and there are ways to further reduce the overhead). I still have a couple of more experiments to do, after which I will share my results and explanation. </div><div><br></div><div>Thanks for working on this.</div><div><br></div><div>David</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 23, 2015 at 10:34 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"><div class="HOEnZb"><div class="h5">><br>
>> On Apr 14, 2015, at 11:56 AM, <a href="mailto:betulb@codeaurora.org">betulb@codeaurora.org</a> wrote:<br>
>><br>
>>><br>
>>> On 04/10/2015 09:25 AM, <a href="mailto:betulb@codeaurora.org">betulb@codeaurora.org</a> wrote:<br>
>>>>> On 04/09/2015 11:06 AM, Betul Buyukkurt wrote:<br>
>>>>>> In <a href="http://reviews.llvm.org/D8908#153838" target="_blank">http://reviews.llvm.org/D8908#153838</a>, @reames wrote:<br>
>>>>>><br>
>>>>>>> Have the IR level construct patches made it up for review? If so,<br>
>>>>>>> can<br>
>>>>>> So far I've posted two patches. These two patches should apply<br>
>>>>>> cleanly<br>
>>>>>> to the tip, working with the present profile infrastructure. The<br>
>>>>>> next<br>
>>>>>> set of patches will be the enabler ones: i.e. three more patches one<br>
>>>>>> for<br>
>>>>>> each of clang, llvm and compiler-rt. Clang patch will be up for<br>
>>>>>> review<br>
>>>>>> later today.<br>
>>>>>><br>
>>>>>>> you send me a link? I managed to miss them.<br>
>>>>>> So far there is this patch and the instrinsic instruction<br>
>>>>>> definitions:<br>
>>>>>> <a href="http://reviews.llvm.org/D8877" target="_blank">http://reviews.llvm.org/D8877</a>. All patches are necessary for getting<br>
>>>>>> the<br>
>>>>>> IC targets and having them displayed by the llvm-profdata.<br>
>>>>> Ok, I'm really not convinced that the instrumentation code needs to<br>
>>>>> be<br>
>>>>> or should be an intrinsic. This seems like something which should be<br>
>>>>> emitted by the frontend and optimized like any other code. To say<br>
>>>>> this<br>
>>>>> a different way, my instrumentation is going to be entirely different<br>
>>>>> than your instrumentation.<br>
>>>>><br>
>>>>> Having said that, I really don't care about this part of the proposed<br>
>>>>> changes since they aren't going to impact me at all. I'm am<br>
>>>>> specifically not objecting to the changes, just commenting. :)<br>
>>>>>>> I'm assuming this will be some type of per call site metadata?<br>
>>>>>> We do assign metadata at the indirect call sites. Format looks like<br>
>>>>>> as<br>
>>>>>> follows:<br>
>>>>>><br>
>>>>>> !33 = metadata !{metadata !"indirect_call_targets", i64<br>
</div></div>>>>>>> <total_exec_count>, metadata !"target_fn1†, i64<br>
>>>>>> <target_fn1_count>,<br>
>>>>>> metadata !"target_fn2†, i64 <target_fn2_count>, ….}<br>
<span class="">>>>>>><br>
>>>>>> Currently, we're recording only the top most called five function<br>
>>>>>> names<br>
>>>>>> at each indirect call site. Following the string literal<br>
</span>>>>>>> “indirect_call_targets†are the fields <total_exec_count><br>
<div><div class="h5">>>>>>> i.e. a<br>
>>>>>> 64<br>
>>>>>> bit value for the total number of times the indirect call is<br>
>>>>>> executed<br>
>>>>>> followed by the function names and execution counts of each target.<br>
>>>>> This was the part I was trying to ask about. I really want to see<br>
>>>>> where<br>
>>>>> you're going with this optimization wise. My naive guess is that<br>
>>>>> this<br>
>>>>> is going to be slightly off for what you actually want.<br>
>>>>><br>
>>>>> Assuming you're going for profile guided devirtualization (and thus<br>
>>>>> inlining), being able to check the type of the receiver (as opposed<br>
>>>>> to<br>
>>>>> the result of the virtual lookup) might be advantageous. (Or, to say<br>
>>>>> it<br>
>>>>> differently, that's what I'm used to seeing. Your approach might be<br>
>>>>> completely reasonable, it's just not what I'm used to seeing.) Have<br>
>>>>> you<br>
>>>>> thought about the tradeoffs here?<br>
>>>> Not sure if I understood the problem here,<br>
>>> First, I am not trying to say there is a problem with your approach; I<br>
>>> am only saying that it's not what I would have expected based on past<br>
>>> experience. You may be entirely correct in your approach, you just<br>
>>> need<br>
>>> to convince me of that. :)<br>
>>>> however, we're recording both<br>
>>>> the target address and the addresses/names of the instrumented<br>
>>>> functions<br>
>>>> during the execution of the instrumented binary. During profile<br>
>>>> reading<br>
>>>> these addresses are used to match the target addresses to<br>
>>>> corresponding<br>
>>>> functions.<br>
>>> Ok, let's start from the basics. For profile guided devirtualization,<br>
>>> you're constructing a cache from (something) to function pointer and<br>
>>> using that cache lookup to enable inlining of the hot target. You have<br>
>>> two standard choices on what to use as your cache key: the result of<br>
>>> the<br>
>>> virtual lookup and the inputs to the virtual lookup.<br>
>>><br>
>>> Option 1 - Inputs to virtual lookup<br>
>>> if ((receiver, vtable index) == what I predicted)<br>
>>> tartget_I_predicted(); // inline me!!<br>
>>> else {<br>
>>> target = full virtual dispatch();<br>
>>> target();<br>
>>> }<br>
>>><br>
>>> Option 2 - result of virtual lookup<br>
>>> target = full virtual dispatch();<br>
>>> if ('target' == what I predicted)<br>
>>> tartget_I_predicted(); // inline me!!<br>
>>> else {<br>
>>> target();<br>
>>> }<br>
>>><br>
>>> You seem to be proposing option 2. I'm saying that I'm used to seeing<br>
>>> option 1 used. Both approaches have their appeal, I'm just asking you<br>
>>> to explain *why* you've chosen the one you apparently have.<br>
>><br>
>> Not all indirect calls occur from C++ like codes. We're profiling and<br>
>> optimizing out indirect calls from C codes as well. We're seeing up to<br>
>> 8%<br>
>> gains on individual benchmarks in spec. This was measured on our<br>
>> platform.<br>
><br>
> We could also consider a hybrid that uses option 1 for vtable calls and<br>
> option 2 for general function pointer calls. For cases where the code<br>
> calls several virtual functions on the same object, profiling for option 1<br>
> could be more efficient if we only record the type of the object once. I<br>
</div></div>> have no idea if that is worthwhile but it’s another possibility.<br>
><br>
> SPEC results are interesting, but I’d be much more interested to hear<br>
<span class="">> how it works for clang. If you build clang with this profiling enabled,<br>
> what is the time and memory overhead? How much bigger are the profile data<br>
> files?<br>
<br>
</span>We've instrumented clang using clang-tip. We collected profile data from<br>
clang using one of the spec benchmarks under -O3. The benchmark was<br>
composed of 16 files.<br>
<br>
Total size of raw profile files:<br>
Original IC-profiling Increase<br>
4031666760 <a href="tel:5063229256" value="+15063229256">5063229256</a> %25.6<br>
<br>
Total size of merged profile file:<br>
Original IC-profiling Increase<br>
65681320 65973768 %.44<br>
<br>
Average of three runs(using time):<br>
Original IC-profiling Increase<br>
47.38 55.73 %17.6<br>
<br>
The above numbers are collected from compiling the whole benchmark. We've<br>
the IC profile data collected from clang. If there is interest we can<br>
share the data w/ the community.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Betul<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> If you then rebuild clang with PGO, how much does it speed things<br>
> up?<br>
><br>
><br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>