LinkModules fails to remap types

[llvmbot]

Bugzilla Link	11464
Resolution	FIXED
Resolved on	Jan 17, 2012 08:20
Version	trunk
OS	MacOS X
Reporter	LLVM Bugzilla Contributor
CC	@asl,@lattner,@efriedma-quic

Extended Description

I've got two simple c files with va_lists:

a.c:

#include <stdarg.h>
void fn1(va_list args) {}

b.c:

#include <stdarg.h>
void fn2(va_list args) {}

If I compile these to bitcode with clang and then link with llvm-link, I get an output module that has two different va_list types:

%struct.__va_list_tag = type { i32, i32, i8*, i8* }
%struct.__va_list_tag.0 = type { i32, i32, i8*, i8* }

define void @​fn1(%struct.__va_list_tag* %args) nounwind uwtable ssp {
%1 = alloca %struct.__va_list_tag*, align 8
store %struct.__va_list_tag* %args, %struct.__va_list_tag** %1, align 8
ret void
}

define void @​fn2(%struct.__va_list_tag.0* %args) nounwind uwtable ssp {
%1 = alloca %struct.__va_list_tag.0*, align 8
store %struct.__va_list_tag.0* %args, %struct.__va_list_tag.0** %1, align 8
ret void
}

Having read the type system rewrite blog post, it seems like LinkModules should be merging these types. After tracking this down in lib/Linker/LinkModules.cpp, it seems that the TypeMap only learns types that it sees in "stuff" that will overlap between the Dst and Src modules. Since fn2 doesn't overlap with fn1, the TypeMap never tries to merge the two different va_list names, producing a duplicate.

I'm not sure if this falls under the category of expecting to be able to find a "magic IR type" or not.

[llvmbot]

I am almost sure this one is a "working as intended". The two uses of va_list never cross, so the type merging doesn't need to merge them. I tried a small variation of your test:

$ cat a.c
#include <stdarg.h>
void fn2(va_list args);
void fn1(va_list args) {
fn2(args);
}

$ cat b.c
#include <stdarg.h>
void fn2(va_list args) {}

and I get only one type for va_arg when I link the IL files.

[lattner]

Yes, this is behaves correctly. We could add a hack to the linker to try to do prefix matching on stuff like this, but it's not clear to me that it matters. Why does this matter to you?

[llvmbot]

For my application, we're loading a bunch of code from bitcode and then generating new IR (in the same module) that calls into it. So when we generate a call to a function that takes a va_list, we do:

llvm::Type* vaListTy = module->getNamedType("struct.__va_list_tag");
...
llvm::Value* vaList = builder->CreateAlloca(vaListTy);
... manipulate the vaList ...
builder->CreateCall(SomeVaListFn, vaList);

The call then blows up because the types don't match between our alloca and the argument type. Moreover, we have code that looks like this:

assert(fnType->getParamType(someIndex) == pointerToVaListTy);

To work around the calls not matching wrt types, I can use bitcasts. Unfortunately though, that means casting to whatever the type the function parameter has come up with, which means I can't have both my asserts and match the callee's type (except perhaps by duplicating the 'types are isomorphic' code from LinkModules).

While my example is in terms of va_lists, there are clearly lots of other "duplicate" types going on. This is clearly part of the type rewrite design (some types will get duplicated and suffixed, be ready), which I'm on-board with. I just feel that it be within the spirit of the new type system for the linker to be more aggressive in folding isomorphic types for me. Moreover, with just a few dozen .bc files linked together you can quickly end up with lots of duplicates that hinder readability compared to llvm29.

[lattner]

FYI, this was fixed in r146728, but got temporarily reverted. I'm working on it.

[lattner]

Fixed in r146932.

[llvmbot]

Finally got a chance to test this and fixes my problem nicely! I now get working code plus nicer IR than 2.9. Thanks.

[llvmbot]

code which fails to link after the patch
The fix to this bug (r146932) causes linking of some modules fail.

It would seem that when the types being merged contain structs inside them, the structs inside them are not correctly merged, and then verifier thinks the bitcode is broken.

the tar.bz2 contains files which link correctly with llvm-svn revision 146931 but fail to link on revision 146932.

how to reproduce:

unpack the tar.bz2 package, go to the directory, run:

llvm-ld -disable-opt *.o *.a -o foo

(the .o files are just .bc files, and .a file ar archive containing bc's)

[lattner]

Please open new bugs for new problems. Just because this looks related, doesn't mean its the same thing.

[llvmbot]

Well, my problem was caused by a fix to this bug, so it seems the fix to this bug is buggy. but I opened a new report.