[LLVMdev] inefficiencies in ConstantUniqueMap ?

[Duncan Sands]

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 struct

In 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.