[LLVMdev] Marking source locations without interfering with optimization?

[Michael McCracken]

On 8/23/05, Chris Lattner <sabre at nondot.org> wrote:
> On Tue, 23 Aug 2005, Michael McCracken wrote:
> >> Okay...  this is tricky.  Anything that will bind to variables will
> >> prevent modification to the variable.
> >
> > I see - so if I wanted to use my earlier approach, I'd need to change every
> > optimization and analysis to treat the 'marker' instructions specially as
> > instructions that don't modify their argument, a big mess...
> 
> exactly.
> 
> > So it sounds like the only way to really not interfere with
> > optimizations is to avoid
> > binding to the variables, which means that if instructions are moved
> > or copied, the markers I add won't be moved or copied along with the
> > instruction. I was hoping to find a scheme that'd stay (mostly)
> > up-to-date through modifications with minimal extra changes.
> 
> I don't really think there is a good way to do that.

That's pretty much what I was afraid of. 
However, it seems like making the modifications to try to keep these
intrinsic calls near the values they refer to, and to duplicate them
intelligently when copying blocks or instructions, would be easier
than what's involved with a new instruction.

Any comments on using the annotation classes for this? It only seems
to be used by  codegen, but it might be appropriate for this kind of
'loose' source info.

I'll dig around some more in the code. Thanks for the help.

> >> I would suggest something like
> >> this (C syntax for the llvm code):
> >>
> >> int foo() {
> >>    %A = alloca int
> >>    llvm.myintrinsic("A", whatever data you want")
> >> }
> >
> > Just to clarify, you're suggesting that I use the LLVM value's name to
> > link up with the source info instead of actually binding to it - so in
> > a slightly more complicated example I might do this:
> >
> > C code:
> >
> > 1: a = foo();
> > 2: b = bar();
> > 3: a = a + b;
> >
> > llvm code:
> >
> > %a = call foo()
> > llvm.myintrinsic("%a", "a", 1)
> > %b = call bar()
> > llvm.myintrinsic("%b", "b", 2)
> > %tmp.1 = add %a, %b
> > llvm.myintrinsic("%tmp.1", "a", 3)
> 
> Exactly.  The %'s are a figment of the asmprinter's imagination, so you
> wouldn't need to include them, but this is basically what I was getting
> at.

OK.

> -Chris
> 
> >> Given the above, you can use the constant string "A", to look up things in
> >> the symbol table of the function.  You will probably want to accept "A"
> >> and anything that starts with "A.".
> >>
> >>> So, I thought one way to go would be to introduce an instruction meant
> >>> just for marking the source location of a value - it'd consume a value
> >>> and some constants marking the location - then the front end could
> >>> generate it (not by default!) where necessary to make sure a value
> >>> could be traced back to its source location. It'd either be lowered
> >>> away or it'd have to be ignored during codegen since we might still
> >>> want to know that info then, for instance, to track register spills
> >>> back to which variable spilled.
> >>
> >> I think the above will work for you, you can make it ignored or deal with
> >> it however you want using the intrinsic lowering code.  Check out how
> >> other intrinsics are handled (e.g. llvm.isunordered, which is handled by
> >> the code generators and llvm.dbg.* which are not) for ideas.
> >>
> >>> What problems can you think of with that approach? Am I asking for
> >>> trouble with passes, or would a semantically meaningless 'marker'
> >>> instruction be OK?
> >>
> >> I'd seriously suggest using an intrinsic instead of an instruction: they
> >> are far far easier to add.  Aside from that, using the symbol table is
> >> really the only thing that will work, and is prone to obvious problems,
> >> but should work pretty well in practice.
> >>
> >>> If you have suggestions for a better way to do this, that'd be great.
> >>> There isn't a lot of prior work I found on this, most of what I saw
> >>> was about debug info, which as I stated, is not quite what I need.
> >>
> >> Hope this helps!
> >
> > It's certainly given me lots to think about.
> >
> > Thanks,
> > -mike
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> 
> -Chris
> 
> --
> http://nondot.org/sabre/
> http://llvm.org/
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 


-- 
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/blog/