[LLVMdev] Lack of use of LLVMContextImpl::NamedStructTypes

[Garrison Venn]

Hi Chris,

Ok, it looks like I need to get my head out of the JIT world where linking between different
modules is done by hand--well it use to be via ExecutionEngine::updateGlobalMapping(...),
and therefore a developer controlled event.

Thanks for the explanation

Garrison

On Jul 27, 2011, at 11:05, Chris Lattner wrote:

> On Jul 26, 2011, at 4:03 AM, Garrison Venn wrote:
>>> Hi Garrison,
>>> 
>>> Do the other two threads answer the question here?
>>> 
>>> -Chris
>> 
>> Yes I believe the other threads concerning the same issue answer why the system, because
>> of the lack of type linkage, is lenient in "unioning" types. What I'm still uncomfortable with is, I
>> don't understand under what conditions the system should union two opaque types with the
>> same name and def. The above method BitcodeReader::ParseTypeTableBody, never seems to do 
>> this, and therefore my reading of Linker::LinkInFiles won't do it either for say two bitcode files
>> accessing/realizing the same named StructType.
> 
> The idea is that the linker does this when there is linkage that implies that two types should be unioned.  For example:
> 
> %A = type opaque
> @G = external global %A*
> ...and...
> 
> %A = type { i32 }
> @G = global %A* null
> 
> should merge the two %a's, because that is implied by linking @G and there is no structural conflict.
> 
>> On the other hand when hand coding two
>> modules using in memory IR, I have a choice in either checking with NamedStructTypes to to force
>> two equivalently named struct types to resolve to the same struct type with the same name, or
>> ignoring the issue, and just have each module create two different struct types (via StructType
>> name collision behavior), with different names but with the same definition. Does the name
>> matter given that the definitions are the same?
> 
> For linking or IR generation?  In IR generation, names matter for purposes of type identity and equality.  The linker cannot assume that linked symbols have the same type (for many reasons), so type merging is "nice to have" for it.
> 
> -Chris