[LLVMbugs] [Bug 11464] New: LinkModules fails to remap types

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=11464

             Bug #: 11464
           Summary: LinkModules fails to remap types
           Product: new-bugs
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: boulos at cs.stanford.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


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.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.