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

Robinson, Paul via llvm-dev llvm-dev at lists.llvm.org
Mon May 8 17:40:17 PDT 2017


(adding back llvm-dev)

Is there any standard means to add an extra field to LLVM IR instructions?

Your description implies that you are not intending to change the on-disk format, so it's simple:
It is a class.  Change the source to add a field to it.  Use it as you wish.
--paulr

From: its.dipanjan.das at gmail.com [mailto:its.dipanjan.das at gmail.com] On Behalf Of Dipanjan Das
Sent: Monday, May 08, 2017 1:45 PM
To: Robinson, Paul
Subject: Re: [llvm-dev] Computing unique ID of IR instructions that can be mapped back


Hi Paul,

On 8 May 2017 at 10:50, Robinson, Paul <paul.robinson at sony.com<mailto:paul.robinson at sony.com>> wrote:
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.

Two tactics come to mind.  First, you can store the ID directly in the instruction (adding a field to the class) when you assign the IDs.

Is there any standard means to add an extra field to LLVM IR instructions?

Second, you can build a map of instr_ptr to ID which you store somewhere that your instrumentation phase can use to look up the IDs as needed.

As instr_ptr keeps on changing, the mapping isn't not going to work.

Presumably you are not looking to modify the bitcode format itself, as you were worried about consistent IDs across runs.
--paulr



--

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


More information about the llvm-dev mailing list