[LLVMdev] Linking opaque types

[Chris Lattner]

On Jul 25, 2011, at 8:52 AM, Anton Lokhmotov wrote:
> There is an issue with representing opaque types in LLVM IR modules: if two
> modules are using the same opaque type (which is only going to be
> specialised at some later stage), it is only identified by its name.  But
> the current module linker "resolves" this as if there is a name clash, and
> one of that opaque types is renamed.  It contradicts an intuitively expected
> identifier behaviour and makes it literally impossible to use opaque types
> for identifying underspecified types across different modules. 
> 
> Our position is that structure type names should be treated as proper
> identifiers, as long as types are structurally equivalent, and all the
> opaque types are structurally equivalent unless they're specialised.
> 
> Could anyone familiar with the linker comment please?

Hi Anton,

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.

This means that when linking:

%A = type { i32 }
and
%A = type opaque

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:

%A = type { i32 }
@G = external global %A
... and ...
%A = type { float}
%G = global %A { float 1.0 }

Even though the two globals *do* have type linkage and the types are contradictory.


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.

-Chris