Jonathan Roelofs via llvm-dev
2017-May-09 01:14 UTC
[llvm-dev] Computing unique ID of IR instructions that can be mapped back
On 5/8/17 6:40 PM, Robinson, Paul via llvm-dev wrote:> (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.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. Jon> > --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 > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor Embedded / Siemens
Dipanjan Das via llvm-dev
2017-May-09 02:34 UTC
[llvm-dev] Computing unique ID of IR instructions that can be mapped back
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170508/2f6f1ee2/attachment.html>
George Burgess IV via llvm-dev
2017-May-09 05:12 UTC
[llvm-dev] Computing unique ID of IR instructions that can be mapped back
> Isn't Instruction* a pointer to the instruction in memory? If so, it'llchange 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>