Hi Jay,> As I understand it, PATypeHolder, OpaqueType and the Module's > TypeSymbolTable are gone. Instead, StructTypes can optionally be > named, and if they are then: > > - they use name equivalence instead of structural equivalence. > - you can create them without any fields, and then add the fields > later when the struct is complete.I find this distinction between structs with names and structs without names strange. Why is a name relevant to anything? If you can add fields to a struct with a name why not to a struct without a name? Ciao, Duncan.
On 30 June 2011 14:07, Duncan Sands <baldrick at free.fr> wrote:> Hi Jay, > >> As I understand it, PATypeHolder, OpaqueType and the Module's >> TypeSymbolTable are gone. Instead, StructTypes can optionally be >> named, and if they are then: >> >> - they use name equivalence instead of structural equivalence. >> - you can create them without any fields, and then add the fields >> later when the struct is complete. > > I find this distinction between structs with names and structs without > names strange. Why is a name relevant to anything? If you can add fields > to a struct with a name why not to a struct without a name?It's Chris's design and I don't feel qualified to speak on his behalf. But... isn't this just the way C works? Structs either have a tag, or some fields, or both, but definitely not neither? And structs with the same tag are the same type in C, which is why the name is relevant. Jay.
Hi Jay,>>> As I understand it, PATypeHolder, OpaqueType and the Module's >>> TypeSymbolTable are gone. Instead, StructTypes can optionally be >>> named, and if they are then: >>> >>> - they use name equivalence instead of structural equivalence. >>> - you can create them without any fields, and then add the fields >>> later when the struct is complete. >> >> I find this distinction between structs with names and structs without >> names strange. Why is a name relevant to anything? If you can add fields >> to a struct with a name why not to a struct without a name? > > It's Chris's design and I don't feel qualified to speak on his behalf. > But... isn't this just the way C works? Structs either have a tag, or > some fields, or both, but definitely not neither? And structs with the > same tag are the same type in C, which is why the name is relevant.thanks for the explanation (which I didn't understand :( ). Hopefully Chris will chime in. Ciao, Duncan.
I'll have another go then!> I find this distinction between structs with names and structs without > names strange. Why is a name relevant to anything? If you can add fields > to a struct with a name [...]This corresponds to the following C constructs: struct S; // create struct with name but no fields ... struct S { int i, j; } // add fields to named struct> [...] why not to a struct without a name?This would imply that you were starting with a struct with no name and no fields, which is not something you can create in C: struct; // this isn't a C type! Maybe "adding fields" is bad terminology -- we're really talking about setting the struct's list of fields, which you can only do once. (You can't add yet more fields later.) Jay.
Hi Jay,> I'll have another go then!thanks!>> I find this distinction between structs with names and structs without >> names strange. Why is a name relevant to anything? If you can add fields >> to a struct with a name [...] > > This corresponds to the following C constructs: > > struct S; // create struct with name but no fields > ... > struct S { int i, j; } // add fields to named structIn Ada you can have a forward declaration with fields (known as discriminants), for example: type X (Z : Integer); -- Z is the discriminant type XP is access X; type X (Z : Integer) is record P : XP; -- Add an additional field, now there are two end record; I don't think this will cause any problems since GCC has resolved the type by the time it hits dragonegg (i.e. dragonegg doesn't see the incomplete type). In llvm-gcc we would see the incomplete type, but I don't care about llvm-gcc any more :)>> [...] why not to a struct without a name? > > This would imply that you were starting with a struct with no name and > no fields, which is not something you can create in C: > > struct; // this isn't a C type!I see structs with fields but without names come flying out of gcc for C++ code all the time. I'm not sure where they come from - perhaps they are utility types created by the front-end. These are probably harmless since then can just be given an invented name. Or maybe it is harmless to let them have no name.> Maybe "adding fields" is bad terminology -- we're really talking about > setting the struct's list of fields, which you can only do once. (You > can't add yet more fields later.)The name-noname distinction still seems artificial to me. I assume it is being driven by efficiency considerations: i.e. not allowing named types to be refined simplifies LLVM's internals considerably. Ciao, Duncan.
On Jun 30, 2011, at 6:07 AM, Duncan Sands wrote:>> - they use name equivalence instead of structural equivalence. >> - you can create them without any fields, and then add the fields >> later when the struct is complete. > > I find this distinction between structs with names and structs without > names strange. Why is a name relevant to anything? If you can add fields > to a struct with a name why not to a struct without a name?The issue is that we have two cases here: 1. anonymous structs which are just used for aggregation, but that are uniqued by-structure. This is mostly useful for simple things like complex numbers, which you want the type to expand inline in .ll files etc. 2. named structs which are uniqued by (obviously their name). The subcase of #2 is that we want a "named struct without a name" because we want the -strip pass to still be useful. Because there is a semantic difference between named and unnamed types, I chose to call them "anonymous" structs, which don't have an identity, and "named" types whose name is allowed to be empty. I plan to rename StructType::get to StructType::getAnon after the branch lands. -Chris