[LLVMdev] Lack of use of LLVMContextImpl::NamedStructTypes

[Garrison Venn]

Thanks for the response Chris,

On Jul 26, 2011, at 0:44, Chris Lattner wrote:

> 
> On Jul 25, 2011, at 10:50 AM, Garrison Venn wrote:
> 
>> Several people on this list have reported issues with the linker regarding a 
>> named StructType instance with the same name in two different modules
>> being resolved into two StructTypes with different names due to StructType::
>> setName(…) collision behavior. Looking at BitcodeReader::ParseTypeTableBody(…),
>> I don't see use of LLVMContextImpl::NamedStructTypes or of Module::getTypeByName(…).
>> Nor do I see this use anywhere else in BitcodeReader's implementation (.cpp file).
>> 
>> Doesn't the context's NamedStructTypes (checking for a previously created StructType 
>> with the same name), have to be used before setName(…) is called so that a new structure
>> is not erroneously created?
> 
> 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. 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?

Regardless unless you feel there is some pedagogic value to the list, you can ignore my lack of 
understanding here because I'm now pretty sure I'm just creating noise that will be resolved
for me by writing tests; not just by looking at code where I'm am probably missing something
anyway. If there is a more concrete question I can ask, when looking at my tests, I'll ask again
then.

Thanks again

Garrison