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

[Daniel Berlin via llvm-dev]

Right.
As folks have told you, the following loop will always give the same
instructions in the same order given the same input IR:


for (auto &BB : F)
  for (auto &I : BB)
      Instruction *IPtr = &I;

Thus, you only need to give them an id based on the order you see them.

If you need something you can access outside of llvm as well, you could
also rename each instruction to the id number using setName.


On Mon, May 8, 2017 at 10:12 PM, George Burgess IV via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> > Isn't Instruction* a pointer to the instruction in memory? If so, it'll
> change across runs
>
> Correct, but none of this is meant to be stored across runs, so the actual
> address doesn't matter. You recompute the map every time your IR is loaded.
>
> On Mon, May 8, 2017 at 7:34 PM, Dipanjan Das via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>>
>> On 8 May 2017 at 18:14, Jonathan Roelofs <jonathan at codesourcery.com>
>> wrote:
>>
>>> An alternative way to do it, which would be less invasive and more
>>> upstreaming friendly, would be to implement this as an analysis pass.
>>>
>>> In the pass, calculate a map<Instruction*,ID>, and use that as the
>>> analysis result. Then query that result for the ID where you need it. If
>>> you've written the analysis correctly, then you'll always get the same IDs
>>> for the same instructions given the same input IR.
>>>
>>
>> Isn't Instruction* a pointer to the instruction in memory? If so, it'll
>> change across runs.
>>
>>
>> --
>>
>> Thanks & Regards,
>> Dipanjan
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170508/fc9636cf/attachment.html>