[llvm-commits] [llvm] r135172 - /llvm/trunk/lib/Transforms/Utils/ValueMapper.cpp

[Devang Patel]

On Jul 14, 2011, at 1:28 PM, Chris Lattner wrote:

> 
> On Jul 14, 2011, at 1:12 PM, Devang Patel wrote:
> 
>>> +++ llvm/trunk/lib/Transforms/Utils/ValueMapper.cpp Thu Jul 14 13:53:50 2011
>>> @@ -167,9 +167,10 @@
>>>   }
>>> }
>>> 
>>> -  // Remap attached metadata.
>>> +  // Remap attached metadata.  Don't bother remapping DebugLoc, it can never
>>> +  // have mappings to do.
>> 
>> That's not true. llvm-ld attached two .ll files. You should only get two metadata entries for functions (DW_TAG_subprogram) after linking. If you get three, then mapping is broken during linking.
> 
> Thanks for the review Devang.  I'm pretty sure it's true (and only get two subprograms for your example) because the MDNodes backing the DebugLoc are uniqued at the LLVMContext level just like the two loaded modules.
> 
> After linking, I get:
> 
> $  llvm-link a.ll b.ll -S |& grep subpro
> !2 = metadata !{i32 589870, i32 0, metadata !3, metadata !"foo", metadata !"foo", metadata !"", metadata !3, i32 2, metadata !4, i1 false, i1 true, i32 0, i32 0, i32 0, i32 0, i1 false, i32 ()* @foo, null, null} ; [ DW_TAG_subprogram ]
> !7 = metadata !{i32 589870, i32 0, metadata !8, metadata !"bar", metadata !"bar", metadata !"", metadata !8, i32 1, metadata !9, i1 false, i1 true, i32 0, i32 0, i32 0, i32 0, i1 false, i32 ()* @bar, null, null} ; [ DW_TAG_subprogram ]
> 
> Linking the other way I get the same result:
> $ llvm-link b.ll a.ll -S | & grep subpro
> !2 = metadata !{i32 589870, i32 0, metadata !3, metadata !"bar", metadata !"bar", metadata !"", metadata !3, i32 1, metadata !4, i1 false, i1 true, i32 0, i32 0, i32 0, i32 0, i1 false, i32 ()* @bar, null, null} ; [ DW_TAG_subprogram ]
> !7 = metadata !{i32 589870, i32 0, metadata !8, metadata !"foo", metadata !"foo", metadata !"", metadata !8, i32 2, metadata !9, i1 false, i1 true, i32 0, i32 0, i32 0, i32 0, i1 false, i32 ()* @foo, null, null} ; [ DW_TAG_subprogram ]
> 
> Am I missing something here?


I get following

$ llvm-link a.ll b.ll -S |grep subprogram
!2 = metadata !{i32 589870, i32 0, metadata !3, metadata !"foo", metadata !"foo", metadata !"", metadata !3, i32 2, metadata !4, i1 false, i1 true, i32 0, i32 0, i32 0, i32 0, i1 false, i32 ()* @foo, null, null} ; [ DW_TAG_subprogram ]
!7 = metadata !{i32 589870, i32 0, metadata !8, metadata !"bar", metadata !"bar", metadata !"", metadata !8, i32 1, metadata !9, i1 false, i1 true, i32 0, i32 0, i32 0, i32 0, i1 false, i32 ()* @bar, null, null} ; [ DW_TAG_subprogram ]
!16 = metadata !{i32 589870, i32 0, metadata !8, metadata !"bar", metadata !"bar", metadata !"", metadata !8, i32 1, metadata !9, i1 false, i1 true, i32 0, i32 0, i32 0, i32 0, i1 false, null, null, null} ; [ DW_TAG_subprogram ]

These subprogram nodes are reachable through DebugLoc and they are also part of named metadata node !llvm.dbg.sp. So if DebugLoc is not mapped then it'd not point to mapped !llvm.dbg.sp nodes.  Here in my case, !7 is an !llvm.dbg.sp element and !16 is reached through ret instructions's DebugLoc.

-
Devang

-------------- next part --------------
A non-text attachment was scrubbed...
Name: myab.ll
Type: application/octet-stream
Size: 2757 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110714/27cf5070/attachment.obj>