<div dir="ltr">Vedant, Are you concerned about instrumentation run  performance for PGO or for coverage testing? For coverage testing, is coverage information enough or count information is also needed?  Depending on the answer to the questions, the solution may be very different.<div><br></div><div>If the answer is for PGO, the a much better longer term solution is to migrate to use IR based instrumentation. Not only because IR based instrumentation places counter update 'optimally', the early optimization including pre-inline of tiny funcs is very effective in reducing instr overhead plus the benefit of better profile quality due to context sensitivity. For more details or performance numbers see Rong's RFC about late instrumentation.</div><div><br></div><div>If the answer is PGO, but for various reasons, the FE based instrumentation has to be used, then I think there is another more effective way previously suggested by Sean. Basically you can skip single BB functions completely during instrumentation. There are various reasons why profile data for single bb function is not useful:</div><div>1) they are usually small and beneficial to be inlined regardless of profile data</div><div>2) the BB of the inline instance can get profile data from the caller context</div><div>3) the profile data for the out of line single BB func is also useless</div><div><br></div><div>Rong has some data showing the effectiveness of this method -- not as good as the pre-optimization approach, but IIRC also very good.</div><div><br></div><div>If the answer is for coverage but the actual count value does not really matter, then a more effective way of reducing overhead is to teach the instrumentation lowering pass to lower the counter update into a simple store:</div><div><br></div><div>  counter_1 = 1;</div><div><br></div><div>Such stores from the inline instances of the same func can be easily eliminated. It will also help multithreaded program a lot when there is heavy counter contention. </div><div><br></div><div>Another benefit is that the size of the counter can be effectively reduced to 1  byte instead of 8 byte.</div><div><br></div><div>The tricky situation is you want coverage data but count per line is also important -- but I wonder having special pass to just handle this scenario is worth the effort.</div><div><div><br></div><div><br></div><div>Also a side note, I think longer term we should unify three instrumentation mechanism into one: FE based, IR based, and old gcda instrumentation.  IR based is the most efficient implementation -- when combined with gcda profiling runtime, it can be used to replace current gcda profiling which is not efficient. It is also possible to use IR based instr for coverage mapping (with coverage map format mostly unchanged) but main challenge is passing source info etc.</div><div><br></div><div>thanks,</div><div><br></div><div>David</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 10, 2016 at 7:21 PM, Vedant Kumar via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I'd like to add a new pass to LLVM which removes redundant profile counter<br>
updates. The goal is to speed up code coverage testing and profile generation<br>
for PGO.<br>
<br>
I'm sending this email out to describe my approach, share some early results,<br>
and gather feedback.<br></blockquote><div><br></div><div>From your example, it seems only one scenario is handled -- local function with single callsite ? This seems to be quite narrow in scope. Before pursuing further, it is better to measure the impact of this on larger benchmarks.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
thanks<br>
vedant<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div></div></div></div>