[llvm-dev] Computing unique ID of IR instructions that can be mapped back

Dipanjan Das via llvm-dev llvm-dev at lists.llvm.org
Fri May 5 09:37:04 PDT 2017


On 5 May 2017 at 09:20, Daniel Berlin <dberlin at dberlin.org> wrote:

> When you say the ID must survive across runs, you mean that instructions
> that look the same must have the same ID?
> Or that the instructions from the first run must have the same ID?
>

If I don't change the bitcode, each instruction should receive the same ID
at every run.


> Because doing a unique positive ID is easy.
> Things are always constructed in the order they appear in the file.
> 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.
>

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.


>
>
> On Thu, May 4, 2017 at 4:47 PM, Dipanjan Das via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>> I am writing an analysis pass on LLVM which requires to:
>>
>>    [1] generate unique, positive ID corresponding to each instruction
>>    [2] the ID must survive across runs
>>    [3] given the ID, corresponding instruction has to be mapped back
>>
>> 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?
>>
>> --
>>
>> Thanks & Regards,
>> Dipanjan
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>


-- 

Thanks & Regards,
Dipanjan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170505/dbb7383b/attachment.html>


More information about the llvm-dev mailing list