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

Timur Iskhodzhanov timurrrr at google.com
Wed May 15 05:32:22 PDT 2013

Hi Anders, John,

Is there any reason for AST/VTableBuilder.{h,cpp} to be in AST?

I think these classes are only used in CodeGen.
Here is an approximate list of files that use VTableContext,
VTableLayout and VTableComponent:

The reason I'm asking is because the current code layout makes it
harder to add support for Microsoft ABI vftables.

Instead of having a single vtable with address points for non-primary
bases (like in Itanium ABI), in Microsoft ABI we need to use a
separate vftable builder for each base with a vfptr.
Thus, we need to define these tables (in CGVTables?) and also emit
stores to vfptrs in class constructors (in CGF?). We should be able to
ask the VTableContext "hey, can you give me a list of virtual tables
I need to define; and what vfptr I should emit stores for".

As you can see, the code for dealing with vtables in ABI-specific way
is currently split
over at least three places, thus making it much harder to add
ABI-specific functionality.
I've just looked at Reid's VBTables patch where he just wrote a
VBTableBuilder in the middle of CGVTables and it's so much simpler to
connect with CodeGen than what I'm doing in VTableBuilder.h for

I believe this should all be available through just one interface
(CGVTables?) which should have different implementations like
ItaniumABIVTables (with VTT) and MicrosoftABIVTables (with VBTables)
to be used from ItaniumCXXABI / MicrosoftCXXABI respectively.
This way, we'll consolidate the V{,F,B}Tables-related code from at
least three different places to just one.
This interface should also provide methods deal with virtual calls as
they slightly differ in these ABIs as well and tied to the vtables.
What do you think about this general direction?

Would you mind if I move AST/VTableBuilder into CodeGen as the first step?

Timur Iskhodzhanov,
Google Russia.

More information about the cfe-dev mailing list