Hello, I'd like to listen your opinions regarding my research with LLVM.<div><div><div><br></div><div>My work is a dynamic analysis of data dependences [1]. Briefly speaking, I'm instrumenting memory loads/stores and loop entries/exits/back edges, and then calculating data dependences in runtime, especially focusing on loop-carried dependences.</div>
<div><br></div><div>So far, I have been working with a binary-level instrumentation tool (Pin). However, doing sophisticated static analysis with binaries is really daunting, so I'm porting my code to LLVM. </div><div>
<br></div><div>The implementation for LLVM is actually simple because my core analysis module is already orthogonal to instrumentation frameworks. So, all I need to do is inserting calls of stub functions that send events to the analysis module (e.g., loop A has been started).</div>
<div><br></div><div>First, instrumenting loop events such as entry/exit/back edges was very straightforward and simple, comparing to my previous binary-level approach, though there was quite a learning curve to use LLVM methods correctly and efficiently. FYI, in a binary-level approach, even extracting loops is challenging. No single pre-header and hard to capture loop exits as well.</div>
<div><br></div><div><br></div><div>However, instrumenting loads and stores efficiently is somewhat tricky. An obvious way is instrumenting every loads and stores, which is what I did with binaries. But, I'd like to filter loads and stores whose dependences can be decided in static time to minimize runtime overhead. Notable examples would be (1) induction variables and (2) local temporary variables:</div>
<div><br></div><div>for (int i = 0; i < N; ++i) {</div><div>  int temp = 10;</div><div>  ...</div><div>}</div><div><br></div><div>In the above example, it is obvious 'i' and 'temp' do not need to be analyzed in runtime. So, I'm writing the code that skip instrumentations for such local scalar variables.</div>
<div><br></div><div>I do believe this is doable. But, as a non-expert in static and compiler-level analysis, implementing such instrumentation code isn't straightforward so far.</div><div><br></div><div>One reason that makes this problem tricky would be I can't do any significant optimizations before instrumentation, because optimizations heavily change code such as loop interchanges, instruction reordering and elimination of variables. I'm currently doing instrumentation before any optimizations.</div>
<div><br></div><div>Such restriction makes some problems: before any optimizations, the IR code isn't a SSA-form, so sophisticated loop analysis is impossible such as identifying induction variable easily. Without SSA form, there are bunch of loads and stores, so extracting such variables require dirty hack.</div>
<div><br></div><div>I think I can implement this loads/stores instrumentation code anyway. However, I'd like to hear opinions from experts on this domain. What would be the most elegant and best approach for this problem? I will appreciate any comments for my work.</div>
<div><br></div><div><br></div><div>Thank you for reading such a long article,</div><div>Minjang</div><div><br></div><div>[1] <a href="http://www.cc.gatech.edu/~minjang/micro10-mjkim.pdf">http://www.cc.gatech.edu/~minjang/micro10-mjkim.pdf</a></div>
</div></div>