[LLVMdev] Marking source locations without interfering with optimization?

[Michael McCracken]

Chris, Thanks for the suggestions.

On 8/22/05, Chris Lattner <sabre at nondot.org> wrote:
> On Fri, 19 Aug 2005, Michael McCracken wrote:
> 
> > I've been thinking of adding an instruction, and I'm following the
> > advice in the docs to consult the list before doing something rash.
> 
> Always a good idea! :)  Instead of adding an instruction, I'd suggest
> adding an intrinsic.  You can mark intrinsics as not reading/writing to
> memory (see lib/Analysis/BasicAliasAnalysis.cpp for example, look for
> llvm.isunordered to see how it is handled).

OK, I didn't know about that - thanks.

> > What I want to do is provide a way to identify variable names and
> > source locations that doesn't affect the effectiveness of
> > optimizations. This is not the same problem as supporting debug info,
> > because I don't care about being able to look up unique names for
> > memory locations or evaluating expressions, etc... I just want to be
> > able to say during an optimization pass what the best guess for the
> > source location and variable names are for a value or instruction that
> > the pass is doing something interesting to.
> 
> 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...

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 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) 


> 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