llvm dev - Aug 2005 - [LLVMdev] Marking source locations without interfering with optimization?

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

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

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

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/