Metadata gets corrupted after linking .bc files

[llvmbot]

Bugzilla Link	10887
Resolution	FIXED
Resolved on	Mar 18, 2013 23:32
Version	trunk
OS	Windows XP
Attachments	Files to reproduce
Reporter	LLVM Bugzilla Contributor
CC	@echristo,@efriedma-quic,@sunfishcode

Extended Description

Windows XP, MSVC 2008
LLVM SVN revision: 138553
clang SVN revision: 138538

I have as input 2 .ll files (It doesn't matter if they're generated by clang or my own frontend) After linking them together (either with llvm-link or llvm::Linker::LinkInFiles), only the first file retains correct llvm.dbg.declare/metadata. The second file just references null metadata.

Correct:
call void @​llvm.dbg.declare(metadata !{i8** %arg0.addr}, metadata !​19), !dbg !​22

Incorrect:
call void @​llvm.dbg.declare(metadata !​18, metadata !​29), !dbg !​30
!​18 = metadata !{null}

Attached are 2 repro-cases:
"1.cmd" contains the steps necessary to reproduce behavior with sample files from my own front-end. Final output file: output1.ll
"2.cmd" contains sample files for clang. Final output file: output2.ll

E.g. in output2.ll you can see correct debug info in lines 10 and 11, and corrupt in lines 23 and 24.

[llvmbot]

Also reproduced with SVN revision 139288 (head)

[llvmbot]

This has nothing to do with debug info. llvm::MapValue() is not mapping metadata with alloca as an metadata operand. Here is a reduced test case :

$ cat one.ll

define i32 @​foo(i8* %arg0) {
entry:
%arg0.addr = alloca i8*, align 8
call void @​llvm.foobar(metadata !{i8** %arg0.addr})
store i8* %arg0, i8** %arg0.addr, align 8
ret i32 42
}

declare void @​llvm.foobar(metadata)

$ cat two.ll

define i32 @​bar(i8* %arg0) {
entry:
%arg0.addr = alloca i8*, align 8
call void @​llvm.foobar(metadata !{i8** %arg0.addr})
store i8* %arg0, i8** %arg0.addr, align 8
ret i32 42
}

declare void @​llvm.foobar(metadata)

$ llvm-link one.ll two.ll -S -o onetwo.ll
$ cat onetwo.ll
; ModuleID = 'one.ll'

define i32 @​foo(i8* %arg0) {
entry:
%arg0.addr = alloca i8*, align 8
call void @​llvm.foobar(metadata !{i8** %arg0.addr})
store i8* %arg0, i8** %arg0.addr, align 8
ret i32 42
}

declare void @​llvm.foobar(metadata)

define i32 @​bar(i8* %arg0) {
entry:
%arg0.addr = alloca i8*, align 8
call void @​llvm.foobar(metadata !​0)
store i8* %arg0, i8** %arg0.addr, align 8
ret i32 42
}

!​0 = metadata !{null}

[llvmbot]

Here is a candidate patch

Index: lib/Transforms/Utils/ValueMapper.cpp

--- lib/Transforms/Utils/ValueMapper.cpp (revision 139698)
+++ lib/Transforms/Utils/ValueMapper.cpp (working copy)
@@ -90,7 +90,7 @@
// is something that is not in the mapping table.
Constant C = const_cast<Constant>(dyn_cast(V));
if (C == 0)

• return 0;

• return const_cast<Value*>(V);

if (BlockAddress *BA = dyn_cast(C)) {
Function *F =

---

Dan, can you review? Thanks.

[sunfishcode]

--- lib/Transforms/Utils/ValueMapper.cpp (revision 139698)
+++ lib/Transforms/Utils/ValueMapper.cpp (working copy)
@@ -90,7 +90,7 @@
// is something that is not in the mapping table.
Constant C = const_cast<Constant>(dyn_cast(V));
if (C == 0)

• return 0;

• return const_cast<Value*>(V);

This seems to interfere with intent of the RF_IgnoreMissingEntries code.

[llvmbot]

What's the use of RF_IgnoreMissingEntries? And how does it interfere ? Thanks.

[sunfishcode]

What's the use of RF_IgnoreMissingEntries? And how does it interfere ? Thanks.

I don't know much beyond what its doxygen comment says. The proposed change interferes because it makes MapValue silently return a valid value when presented a value not in its map, which is different behavior from what callers seem to expect.

[llvmbot]

*** Bug llvm/llvm-bugzilla-archive#11112 has been marked as a duplicate of this bug. ***

[llvmbot]

re: RF_IgnoreMissingEntries

It seems that some types of Values do not need to be in the
incoming ValueMap -- there are some implicit identity mappings:
"// Global values do not need to be seeded into the VM if they
// are using the identity mapping."

So for this bug, are we missing some cases of implicit identity
mappings, or are the callers responsible for setting up an identity
mapping where it's "okay" (the patch attached to pr 11112 seems to
set up the identity mapping for Values of type Instruction (only)
at the callsite in LinkModules)?

If it's missing implicit cases of identity mappings, then I think
the patch also needs to update the ValueMap before
returning: "return VM[V] = const_cast<Value*>(V)"
(at least the other identity mappings do that).

[llvmbot]

Manman says this was fixed in r173946.

[llvmbot]

That change was reverted and replaced by r174093.

[llvmbot]

mentioned in issue llvm/llvm-bugzilla-archive#11112

[llvmbot]

mentioned in issue llvm/llvm-bugzilla-archive#12530