<div dir="ltr">I've tripped over this behaviour as well. I ended up working around the problem by creating a new context every time I wanted to link modules together. Which led to me accidently generating one module using two different contexts. Which isn't an error that is detected by module verification. It only causes issues for comparisons like Type equality that compare pointers, and those types of problems can be tricky to debug.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 27, 2013 at 8:14 PM, Marcus Frenkel <span dir="ltr"><<a href="mailto:marcus.frenkel@fernuni-hagen.de" target="_blank">marcus.frenkel@fernuni-hagen.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I stumbled upon a strange thing regarding types and module linking, which I don't quite get, so maybe someone around here can enlighten me.<br>
<br>
Consider the following code, which will create 2 modules m1 and m2, and a named structured type %T = { i32 }; m1 contains only a function definition f(%T), m2 contains a function declaration f(%T) and a function definition h(%T), where h will call f in its body. Note that all functions in m1 and m2 are based upon the same structured type %T:<br>

<br>
    LLVMContext context;<br>
    BasicBlock* b;<br>
<br>
    // modules<br>
    Module *m1 = new Module( "m1", context ),<br>
           *m2 = new Module( "m2", context );<br>
<br>
    // types<br>
    vector<Type*> types;<br>
<br>
    types.push_back( IntegerType::get( context, 32 ) );<br>
<br>
    Type* sType = StructType::create( types, "T" );<br>
<br>
    types.clear();<br>
    types.push_back( sType );<br>
<br>
    FunctionType* ft = FunctionType::get( Type::getVoidTy( context ), types, false );<br>
<br>
    // m1<br>
    Function* f = Function::Create( ft, GlobalValue::ExternalLinkage, "f", m1 );<br>
<br>
    b = BasicBlock::Create( context, "b", f );<br>
    ReturnInst::Create( context, b );<br>
<br>
    verifyModule(*m1);<br>
<br>
    // m2<br>
    Function* fDecl = Function::Create( ft, GlobalValue::ExternalLinkage, "f", m2 );<br>
    Function* h = Function::Create( ft, GlobalValue::ExternalLinkage, "h", m2 );<br>
<br>
    vector<Value*> args;<br>
    args.push_back( h->arg_begin() );<br>
<br>
    b = BasicBlock::Create( context, "b", h );<br>
    CallInst::Create( fDecl, args, "", b );<br>
    ReturnInst::Create( context, b );<br>
<br>
    verifyModule(*m2);<br>
<br>
<br>
Each module for itself is okay and passes the verification, leading to the following IR code:<br>
<br>
    ; ModuleID = 'm1'<br>
<br>
    %T = type { i32 }<br>
<br>
    define void @f(%T) {<br>
    b:<br>
      ret void<br>
    }<br>
<br>
    =====================<br>
    ; ModuleID = 'm2'<br>
<br>
    %T = type { i32 }<br>
<br>
    declare void @f(%T)<br>
<br>
    define void @h(%T) {<br>
    b:<br>
      call void @f(%T %0)<br>
      ret void<br>
    }<br>
<br>
<br>
However, if both modules are linked together as per<br>
<br>
    // link<br>
    Linker::LinkModules( m1, m2, Linker::DestroySource, nullptr );<br>
    verifyModule(*m1);<br>
<br>
<br>
the type %T in both modules will not be unified, but instead two separate types %T and %0 will be introduced, leading to the following IR code, which of course won't pass the verification any more due to type incompatibilities in the function call:<br>

<br>
    ; ModuleID = 'm1'<br>
<br>
    %0 = type { i32 }<br>
    %T = type { i32 }<br>
<br>
    define void @f(%0) {<br>
    b:<br>
      ret void<br>
    }<br>
<br>
    define void @h(%T) {<br>
    b:<br>
      call void @f(%T %0)<br>
      ret void<br>
    }<br>
<br>
<br>
Even more strange, if both modules and the types are created separately from each other (meaning, that the type %T is created for both modules anew), but within the same LLVMContext, the call to LinkModules will result in a proper module with a unified type %T.<br>

<br>
Is that a bug or a feature of LLVM? I thought that types will be handled at context level and not module level, so that it should be clear that %T in both m1 and m2 can be unified, given that they even are based upon the same llvm::Type type (which becomes even more strange with the fact, that they will be unified, when they are *not* based upon the same llvm::Type type).<br>

<br>
Any explanation of that behavior would be much appreciated!<br>
<br>
<br>
Cheers,<br>
Marcus<br>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div>