llvm dev - Jul 2011 - [LLVMdev] Lack of use of LLVMContextImpl::NamedStructTypes

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

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

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