llvm dev - Aug 2011 - [LLVMdev] metadata linking bug or by design

I looked at an earlier version.  NamedMDNodes were linked after global
values.  Current trunk version links NamedMDNodes before that, though
the comment says otherwise: "We do this after linking GlobalValues so
that MDNodes that reference GlobalValues are properly remapped".  see
ModuleLinker::run in lib/Linker/LinkModules.cpp.

If I move the call to linkNamedMDNodes in ModuleLinker::run to the
last step (just before return false), everything looks good.  Not sure
if linkNamedMDNodes must be called earlier.

- xi

On Thu, Aug 4, 2011 at 1:22 PM, Devang Patel <dpatel at apple.com>
wrote:
>
> On Aug 4, 2011, at 8:21 AM, Xi Wang wrote:
>
>> Hi,
>>
>> It seems that current linker "drops" updated llvm::Value *
references
>> in metadata.  Here goes an example.  We have a two-line source file
>> a.c:
>>
>> static int x;
>> void foo() { x = 1; }
>>
>> and a similar b.c:
>>
>> static int x;
>> void bar() { x = 1; }
>>
>> They both have an internal variable x; one of them will be renamed (to
>> x1) during linking.
>>
>> clang -emit-llvm -c -g a.c
>> clang -emit-llvm -c -g b.c
>> llvm-link -o t.bc a.o b.o
>>
>> Before linking we can see the following lines in both bitcode files
>> from a.c and b.c, where the last element of !5 refers to the internal
>> variable x.
>>
>> !llvm.dbg.sp = !{!1}
>> !5 = metadata !{i32 655412, i32 0, metadata !0, metadata
!"x",
>> metadata !"x", metadata !"", metadata !2, i32 1,
metadata !6, i32 1,
>> i32 1, i32* @x} ; [ DW_TAG_variable ]
>>
>> However after linking the last element of !11 becomes null.  I was
>> expecting that it would refer to the renamed x1.
>>
>> !llvm.dbg.gv = !{!9, !11}
>> !9 = metadata !{i32 655412, i32 0, metadata !0, metadata
!"x",
>> metadata !"x", metadata !"", metadata !3, i32 1,
metadata !10, i32 1,
>> i32 1, i32* @x} ; [ DW_TAG_variable ]
>> !11 = metadata !{i32 655412, i32 0, metadata !1, metadata
!"x",
>> metadata !"x", metadata !"", metadata !7, i32 1,
metadata !12, i32 1,
>> i32 1, null} ; [ DW_TAG_variable ]
>>
>> Is it intentional or a bug?  Thanks.
>
> It's a bug, probably a regression. Please file a bugzilla report.
> Thanks,
> -
> Devang
>

On Aug 4, 2011, at 11:30 AM, Xi Wang wrote:
> I looked at an earlier version.  NamedMDNodes were linked after global
> values.  Current trunk version links NamedMDNodes before that, though
> the comment says otherwise: "We do this after linking GlobalValues so
> that MDNodes that reference GlobalValues are properly remapped".  see
> ModuleLinker::run in lib/Linker/LinkModules.cpp.
> 
> If I move the call to linkNamedMDNodes in ModuleLinker::run to the
> last step (just before return false), everything looks good.  Not sure
> if linkNamedMDNodes must be called earlier.
I made  that change in response to Chris's change ValueMapper. Metadata
mapping is being investigated as part of PR 10553 anyway. So Ill fix this
particular regression you have found.
Thanks!
-
Devang
> 
> - xi
> 
> On Thu, Aug 4, 2011 at 1:22 PM, Devang Patel <dpatel at apple.com>
wrote:
>> 
>> On Aug 4, 2011, at 8:21 AM, Xi Wang wrote:
>> 
>>> Hi,
>>> 
>>> It seems that current linker "drops" updated llvm::Value
* references
>>> in metadata.  Here goes an example.  We have a two-line source file
>>> a.c:
>>> 
>>> static int x;
>>> void foo() { x = 1; }
>>> 
>>> and a similar b.c:
>>> 
>>> static int x;
>>> void bar() { x = 1; }
>>> 
>>> They both have an internal variable x; one of them will be renamed
(to
>>> x1) during linking.
>>> 
>>> clang -emit-llvm -c -g a.c
>>> clang -emit-llvm -c -g b.c
>>> llvm-link -o t.bc a.o b.o
>>> 
>>> Before linking we can see the following lines in both bitcode files
>>> from a.c and b.c, where the last element of !5 refers to the
internal
>>> variable x.
>>> 
>>> !llvm.dbg.sp = !{!1}
>>> !5 = metadata !{i32 655412, i32 0, metadata !0, metadata
!"x",
>>> metadata !"x", metadata !"", metadata !2, i32
1, metadata !6, i32 1,
>>> i32 1, i32* @x} ; [ DW_TAG_variable ]
>>> 
>>> However after linking the last element of !11 becomes null.  I was
>>> expecting that it would refer to the renamed x1.
>>> 
>>> !llvm.dbg.gv = !{!9, !11}
>>> !9 = metadata !{i32 655412, i32 0, metadata !0, metadata
!"x",
>>> metadata !"x", metadata !"", metadata !3, i32
1, metadata !10, i32 1,
>>> i32 1, i32* @x} ; [ DW_TAG_variable ]
>>> !11 = metadata !{i32 655412, i32 0, metadata !1, metadata
!"x",
>>> metadata !"x", metadata !"", metadata !7, i32
1, metadata !12, i32 1,
>>> i32 1, null} ; [ DW_TAG_variable ]
>>> 
>>> Is it intentional or a bug?  Thanks.
>> 
>> It's a bug, probably a regression. Please file a bugzilla report.
>> Thanks,
>> -
>> Devang
>>

Great!  Thanks!

I noticed this when I was creating my own metadata nodes, which
contained references to functions --- after linking some elements that
referred to functions magically became null.

- xi

On Thu, Aug 4, 2011 at 2:42 PM, Devang Patel <dpatel at apple.com>
wrote:
>
> On Aug 4, 2011, at 11:30 AM, Xi Wang wrote:
>
>> I looked at an earlier version.  NamedMDNodes were linked after global
>> values.  Current trunk version links NamedMDNodes before that, though
>> the comment says otherwise: "We do this after linking GlobalValues
so
>> that MDNodes that reference GlobalValues are properly remapped".
 see
>> ModuleLinker::run in lib/Linker/LinkModules.cpp.
>>
>> If I move the call to linkNamedMDNodes in ModuleLinker::run to the
>> last step (just before return false), everything looks good.  Not sure
>> if linkNamedMDNodes must be called earlier.
>
> I made  that change in response to Chris's change ValueMapper. Metadata
mapping is being investigated as part of PR 10553 anyway. So Ill fix this
particular regression you have found.
> Thanks!
> -
> Devang
>
>>
>> - xi
>>
>> On Thu, Aug 4, 2011 at 1:22 PM, Devang Patel <dpatel at
apple.com> wrote:
>>>
>>> On Aug 4, 2011, at 8:21 AM, Xi Wang wrote:
>>>
>>>> Hi,
>>>>
>>>> It seems that current linker "drops" updated
llvm::Value * references
>>>> in metadata.  Here goes an example.  We have a two-line source
file
>>>> a.c:
>>>>
>>>> static int x;
>>>> void foo() { x = 1; }
>>>>
>>>> and a similar b.c:
>>>>
>>>> static int x;
>>>> void bar() { x = 1; }
>>>>
>>>> They both have an internal variable x; one of them will be
renamed (to
>>>> x1) during linking.
>>>>
>>>> clang -emit-llvm -c -g a.c
>>>> clang -emit-llvm -c -g b.c
>>>> llvm-link -o t.bc a.o b.o
>>>>
>>>> Before linking we can see the following lines in both bitcode
files
>>>> from a.c and b.c, where the last element of !5 refers to the
internal
>>>> variable x.
>>>>
>>>> !llvm.dbg.sp = !{!1}
>>>> !5 = metadata !{i32 655412, i32 0, metadata !0, metadata
!"x",
>>>> metadata !"x", metadata !"", metadata !2,
i32 1, metadata !6, i32 1,
>>>> i32 1, i32* @x} ; [ DW_TAG_variable ]
>>>>
>>>> However after linking the last element of !11 becomes null.  I
was
>>>> expecting that it would refer to the renamed x1.
>>>>
>>>> !llvm.dbg.gv = !{!9, !11}
>>>> !9 = metadata !{i32 655412, i32 0, metadata !0, metadata
!"x",
>>>> metadata !"x", metadata !"", metadata !3,
i32 1, metadata !10, i32 1,
>>>> i32 1, i32* @x} ; [ DW_TAG_variable ]
>>>> !11 = metadata !{i32 655412, i32 0, metadata !1, metadata
!"x",
>>>> metadata !"x", metadata !"", metadata !7,
i32 1, metadata !12, i32 1,
>>>> i32 1, null} ; [ DW_TAG_variable ]
>>>>
>>>> Is it intentional or a bug?  Thanks.
>>>
>>> It's a bug, probably a regression. Please file a bugzilla
report.
>>> Thanks,
>>> -
>>> Devang
>>>
>
>