On Mon, Jul 25, 2011 at 9:36 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Jul 25, 2011, at 8:52 AM, Anton Lokhmotov wrote:<br>
> There is an issue with representing opaque types in LLVM IR modules: if two<br>
> modules are using the same opaque type (which is only going to be<br>
> specialised at some later stage), it is only identified by its name.  But<br>
> the current module linker "resolves" this as if there is a name clash, and<br>
> one of that opaque types is renamed.  It contradicts an intuitively expected<br>
> identifier behaviour and makes it literally impossible to use opaque types<br>
> for identifying underspecified types across different modules.<br>
><br>
> Our position is that structure type names should be treated as proper<br>
> identifiers, as long as types are structurally equivalent, and all the<br>
> opaque types are structurally equivalent unless they're specialised.<br>
><br>
> Could anyone familiar with the linker comment please?<br>
<br>
</div>Hi Anton,<br>
<br>
In the new-world-order, the identity of a named structure type is based on the name, but just like before, types have no linkage.<br>
<br>
This means that when linking:<br>
<br>
%A = type { i32 }<br>
and<br>
%A = type opaque<br>
<br>
that these two types are not necessarily unioned.  There are several reasons for this, including that it is completely valid IR to link these two modules:<br>
<br>
%A = type { i32 }<br>
@G = external global %A<br>
... and ...<br>
%A = type { float}<br>
%G = global %A { float 1.0 }<br>
<br>
Even though the two globals *do* have type linkage and the types are contradictory.<br>
<br>
<br>
To handle the fact that types do not (and can not, at least as long as we intend to support obscure languages like "C" :) have linkage, the the linker uses a "best effort" approach.  It attempts to merge types and rewrite IR to use the merged types where it can, but it doesn't make any guarantees.<br>


<font color="#888888"><br></font></blockquote><div>I want to add an additional detail into this mix: That the frontend generating all of this code is making a best effort to insure that the types are in fact compatible -- and it isn't working.</div>

<div><br></div><div>One of the painful things about the old type system was that you were forced to specify every type in excruciating detail - so if I had a type A which had a data member of type B*, I had to include the complete definition of B in my module, even if the module never dereferenced that field - because otherwise my definition of A wouldn't be compatible with another module's definition of A. And if B contained a C* which in turn contained a D*, all of those had to be specified as well, even if the module never used types C or D.</div>

<div><br></div><div>One of the benefits I had hoped to get out of the new system was to be able to "forward declare" a type without giving a definition for it - so if I have my definition of A containing a B*, I only need to declare B as an opaque type instead of giving all the details.</div>

<div><br></div><div>However, it sounds like what you are saying is that if I do this, I can't depend on the linker being able to merge the definition of forward-declared B with fully-specified B, nor A from module 1 (containing forward-declared B*) with A from module 2 (containing fully-specified B*).</div>

<div><br></div><div>If that's true, then it means that we're back to the case where every type has to be fully defined down to the leaf level.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<font color="#888888">
-Chris<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">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/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>-- Talin<br>