[cfe-dev] Move VTableContext & friends from AST to CodeGen?

[Timur Iskhodzhanov]

2013/5/16 John McCall <rjmccall at apple.com>:
> On May 15, 2013, at 12:55 PM, Peter Collingbourne <pcc at google.com> wrote:
>> My opinion is that the VTableContext-level interfaces for the two ABIs (were they to exist) should be two separate interfaces without a base class, since the details are fundamentally different at that level, and that they can later be unified at the CodeGen level.  Since I'm guessing that you don't really need a VTableContext equivalent if you're only interested in LLVM IR generation, you could consider implementing Microsoft vtable stuff wholly within CodeGen, while keeping the Itanium VTableContext in AST.  (With sufficient interest, someone could factor the relevant parts of the Microsoft vtable builder to AST as I did for Itanium.)
>
> I agree that there's really no reason to pretend that there's a common interface here;  we should have an ItaniumVTableContext and a MicrosoftVTableContext.

Well, looking at VTableContext I actually did have a feeling that the
interface is small enough to generalize.
But on the second thought - yeah, I think the VTableContexts should be
different too (not only VTableBuilders).

This way, we'll have to move the BuildVirtualCall into CGCXXABI (as
the exact this adjustments, vptr offsets and vtable indices are
different in different ABIs),
so the abstraction happens in CGCXXABI rather than VTableContext.
I think I'll try to get round CGVTables then and just use
MicrosoftVTableContext directly in the CodeGen's MicrosoftCXXABI.

> However, please maintain the current design where the abstract layout for the vftbl and vbtbl are generated in the AST library and then consumed by IR-generation.
OK, will do.

Thanks!