<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 5 May 2017 at 09:20, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</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">When you say the ID must survive across runs, you mean that instructions that look the same must have the same ID?<div>Or that the instructions from the first run must have the same ID?</div></div></blockquote><div><br></div><div>If I don't change the bitcode, each instruction should receive the same ID at every run.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Because doing a unique positive ID is easy.<br></div><div>Things are always constructed in the order they appear in the file.</div><div>So using a single counter, walking every function in the module, and then every instruction in the function, and giving each an ID, should be unique, positive, and consistent across runs for the same file.</div></div></blockquote><div><br></div><div>Let's say, I walk the file, increment the counter but how'll I assign an  ID to an instruction. Because, I need these IDs during an instrumentation phase. In other words, how will the instrumentation phase know what ID has been assigned to a particular instruction? Because, the instrumentation knows about the instr_ptr (memory address of an instruction) which changes at every run.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 4, 2017 at 4:47 PM, Dipanjan Das 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"><div dir="ltr"><br clear="all"><div>I am writing an analysis pass on LLVM which requires to:</div><div><br></div><div>   [1] generate unique, positive ID corresponding to each instruction</div><div>   [2] the ID must survive across runs</div><div>   [3] given the ID, corresponding instruction has to be mapped back</div><div><br></div><div>For [1], the general suggestion is to use the Value* instr_ptr associated to each instruction. The instr_ptr points to specific instruction in memory, hence unique. However, it does change at every run, thus violating [2]. I have a hacking workaround of getting the first instruction of 'main' method and computing the offset. The problem is, this gives me negative offset for instructions lying in lower memory region than 'main'. Even if I circumvent the problem by adding a positive bias high enough, I have no clue how can I map the instr_ptr back to corresponding IR instruction. Can anyone suggest any elegant workaround?</div><span class="HOEnZb"><font color="#888888"><span class="m_5428463933686247188HOEnZb"><font color="#888888"><div><br></div>-- <br><div class="m_5428463933686247188m_860520926403626692gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span><div><div dir="ltr"><p>Thanks & Regards,</p>
<div>Dipanjan</div></div></div></span></div></div>
</font></span></font></span></div><span class="HOEnZb"><font color="#888888">
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></font></span></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span><div><div dir="ltr"><p>Thanks & Regards,</p>
<div>Dipanjan</div></div></div></span></div></div>
</div></div>