<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">rdtsc is pretty good but keep in mind that the tsc register is not kept consistent across cores. In general, it is consistent across cores on one cpu socket but not across sockets. But I’ve seen cases where there is a huge difference across cores on the same cpu socket. (this was because of bios settings used during the boot cycle.) If you can lock your thread(s) on specific cores, you can avoid these issues.<div><br></div><div>-bean<br><div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><div><div>On Sep 17, 2014, at 1:50 PM, sathvik <<a href="mailto:sathvikl@gmail.com">sathvikl@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">If you are on X86, you can use the rdtsc/rdtscp llvm intrinsics -<br><a href="http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/185208">http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/185208</a><br><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">with RDTSCP you can double fence your basic block so you can be sure that the OOO scheduling does not schedule instructions that you don't intend to measure, however note that there is a huge overhead as a result of this. <br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">RDTSC has a much lower overhead since it only reads your TSC reg but if you are measuring a small basic block it won't be accurate. <br><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">thanks,<br>sathvik <br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"> <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 17, 2014 at 1:35 PM, Vanderson Martins do Rosario <span dir="ltr"><<a href="mailto:vandersonmr2@gmail.com" target="_blank">vandersonmr2@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Jon,<br>I need to create a database of basics blocks and their execution time. The only thing I'm concerned is if a block A is more expensive than a block B.<br>Do you think that even with the overhead I would be able to get the A > B information?<br>Like: overhead + time(A) > overhead + time(B) => A > B.<br>If so, I'm not too much concerned about the accuracy.<br><br>Not sure if I was clear,<br><br>Thanks again<br></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><span style="color:rgb(102,102,102)">Vanderson M. Rosario</span><br></div></div>
<br><div class="gmail_quote">2014-09-17 17:26 GMT-03:00 Jonathan Roelofs <span dir="ltr"><<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a>></span>:<span class=""><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think if you do this, you're quickly going to realize that there's quite a lot of overhead in getting the time stamps needed to record basic block duration, so you're not going to get accurate results except for really big basic blocks.<br>
<br>
<br>
Cheers,<br>
<br>
Jon<div><br>
<br>
On 9/17/14 1:53 PM, Vanderson Martins do Rosario wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
Guys,<br>
<br>
Someone have any idea how could I measure the execution time of each LLVM basic<br>
block of a program?<br>
<br>
I tried to use some profiling tools like gcov and perf, but as far as I know<br>
they can only give me the frequency that each basic block is executed.<br>
<br>
I was thinking about writing a pass to add PAPI instructions in each LLVM basic<br>
block. Do you think is a good idea?<br>
<br>
Thanks<br>
<br>
Vanderson M. Rosario<br>
<br>
<br></div>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">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/<u></u>mailman/listinfo/llvmdev</a><br>
<br><span><font color="#888888">
</font></span></blockquote><span><font color="#888888">
<br>
-- <br>
Jon Roelofs<br>
<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a><br>
CodeSourcery / Mentor Embedded<br>
</font></span></blockquote></span></div><br></div>
<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>
<br></blockquote></div><br></div>
_______________________________________________<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">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></div><br></div></div></div></body></html>