[LLVMdev] Marking source locations without interfering with optimization?

[Chris Lattner]

On Tue, 23 Aug 2005, Michael McCracken wrote:
>>> 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.

As intrinisics, code copying changes should keep them up-to-date: if a 
block is duplicated, the intrinsics will too.

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

Can't really be used.  :(

-Chris

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

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/