[llvm-dev] count how many basic block executed

John Criswell via llvm-dev llvm-dev at lists.llvm.org
Sat Jan 27 13:11:50 PST 2018


On 1/26/18 1:04 AM, Linhai Song via llvm-dev wrote:
>
> Hello everyone,
>
>
> I am writing a pass to instrument program and count how many basic 
> block executed. What I have tried is to instrument a local counter 
> inside each function, add 1 to the local counter inside each basic 
> block, and save the counter value to a global counter. The current 
> runtime overhead is around 25%. Is there any way I can try to lower 
> the overhead? Like keeping the local counter inside a register or 
> applying the path profiling algorithm?
>

By "local counter," I assume you mean that you created an alloca 
instruction that allocates memory and that you increment the value in 
this alloca'ed memory using a load, add, and store instruction. Is that 
correct?

If so, have you tried using the mem2reg pass to convert the local 
counter into a SSA virtual register?  That may speed it up a bit. After 
that, other LLVM optimizations may be able to remove redundant 
instructions or combine additions.

If that isn't enough, then you'll probably need to make your 
instrumentation smarter.  LLVM has passes that you can use to locate 
loops; if the loop has the right structure, you can increment the count 
at the end of the loop.  Likewise, if you can find control equivalent 
basic blocks, you only need to increment the counter in one of them.

Regards,

John Criswell

>
> Thanks a lot!
>
>
> Best,
>
>
>                          Linhai
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180127/623a95a3/attachment.html>


More information about the llvm-dev mailing list