llvm dev - May 2017 - Computing unique ID of IR instructions that can be mapped back

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170508/597304a4/attachment.html>

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>

Thank you very much to you all. I got the idea. Only problem is now to
relate the ID back to a specific IR instruction in case I want to trace
back which ID an instruction corresponds to. I can either write the mapping
on disk or augment the bitcode format to accommodate an ID field (may be).

On 8 May 2017 at 22:19, Daniel Berlin <dberlin at dberlin.org> wrote:
> 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
>>
>>
>

-- 

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