[LLVMdev] type-system-rewrite branch near landing

[Eli Friedman]

On Fri, Jul 8, 2011 at 8:30 AM, Jay Foad <jay.foad at gmail.com> wrote:
> On 7 July 2011 18:41, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Thu, Jul 7, 2011 at 12:55 AM, Jay Foad <jay.foad at gmail.com> wrote:
>>> 2. Even some simple C cases fail, e.g.:
>>>
>>> struct S;
>>> extern struct T {
>>>  struct S (*p)(void);
>>> } t;
>>> struct S { int i; };
>>> void g(void) {
>>>  t.p();
>>> }
>>>
>>> The problem here is that T.p is codegenned as i8*, so we need to
>>> bitcast it to a proper function pointer type before calling it.
>>> Shouldn't be too hard to implement.
>>
>> I don't really like the idea that function types, and especially enum
>> types, will permanently be associated with an incomplete type.
>> There's too much room for something to screw up, particularly for the
>> enum case (which probably won't get tested very well).
>>
>> I think if you keep track of all the types based on an incomplete tag
>> type, and just wipe them all out when the type is completed,
>> everything should just work; a type can't be completed in the middle
>> of the CodeGen for a function, and we bitcast all globals before use,
>> so there's nothing else to change.
>
> When I thought about this very hard, it made sense. Thanks for the insight!
>
> It sounds a bit hard to keep track of which types are based (directly
> or indirectly) on incomplete types, so for the time being I'm clearing
> the whole of the TypeCache and the FunctionInfos cache every time any
> type is completed. I realise this is a bit brutal.

Hmm... I don't have anything simple to suggest here.

> Now I'm running into another problem with the implementation:
> EmitCXXConstructor() and EmitCXXDestructor() don't do most of the
> stuff that's done for normal functions in
> EmitGlobalFunctionDefinition. In particular, they're not prepared to
> find an existing LLVM declaration of the function with the wrong LLVM
> type, and replace it with a definition having the right type.

Hacking in that logic in shouldn't be too hard...  I hate to suggest
copy-paste, but that's probably the easiest thing to do.  It wasn't
necessary before in these cases because the directly relevant types
for a constructor/destructor are guaranteed to be complete before any
use of the declarations.

-Eli