<div dir="ltr">Hi Timur,<div><br></div><div>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.)</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 15, 2013 at 3:31 PM, Timur Iskhodzhanov <span dir="ltr"><<a href="mailto:timurrrr@google.com" target="_blank">timurrrr@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Anders,<br>
Thanks for the historic insight!<br>
<br>
Looks like here are the discussion and the commit:<br>
<a href="http://comments.gmane.org/gmane.comp.compilers.clang.scm/36181" target="_blank">http://comments.gmane.org/gmane.comp.compilers.clang.scm/36181</a><br>
<a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=140510" target="_blank">http://llvm.org/viewvc/llvm-project?view=revision&revision=140510</a><br>
<br>
Peter,<br>
Do you know if PathScale is still working on a WHIRL backend for clang?<br>
  (I believe this was the main rationale for the move to AST)<br>
What exactly do they need to have in AST?<br>
Do they only support one C++ ABI?<br>
<br>
--<br>
Timur<br>
<br>
2013/5/15 Anders Carlsson <<a href="mailto:andersca@icloud.com">andersca@icloud.com</a>>:<br>
> Hi Timur,<br>
><br>
> VTableBuilder actually started its life inside CodeGen, but was moved to AST because someone wanted to be able to use the clang fronted with a non-LLVM backend.<br>
><br>
> I forget the exact details, but I'm pretty sure you can dig through svn or mailing list history and find out.<br>
><br>
> - Anders<br>
><br>
> On May 15, 2013, at 5:32 AM, Timur Iskhodzhanov <<a href="mailto:timurrrr@google.com">timurrrr@google.com</a>> wrote:<br>
><br>
>> Hi Anders, John,<br>
>><br>
>> Is there any reason for AST/VTableBuilder.{h,cpp} to be in AST?<br>
>><br>
>> I think these classes are only used in CodeGen.<br>
>> Here is an approximate list of files that use VTableContext,<br>
>> VTableLayout and VTableComponent:<br>
>>  CGClass.cpp<br>
>>  CGCXX.cpp<br>
>>  CGCXXABI.cpp<br>
>>  CGDebugInfo.cpp<br>
>>  CGExprConstant.cpp<br>
>>  CGExprCXX.cpp<br>
>>  CGRTTI.cpp<br>
>>  CGVTables.cpp<br>
>>  CGVTT.cpp<br>
>>  CodeGenModule.h<br>
>><br>
>> The reason I'm asking is because the current code layout makes it<br>
>> harder to add support for Microsoft ABI vftables.<br>
>><br>
>> Instead of having a single vtable with address points for non-primary<br>
>> bases (like in Itanium ABI), in Microsoft ABI we need to use a<br>
>> separate vftable builder for each base with a vfptr.<br>
>> Thus, we need to define these tables (in CGVTables?) and also emit<br>
>> stores to vfptrs in class constructors (in CGF?). We should be able to<br>
>> ask the VTableContext "hey, can you give me a list of virtual tables<br>
>> I need to define; and what vfptr I should emit stores for".<br>
>><br>
>> As you can see, the code for dealing with vtables in ABI-specific way<br>
>> is currently split<br>
>> over at least three places, thus making it much harder to add<br>
>> ABI-specific functionality.<br>
>> I've just looked at Reid's VBTables patch where he just wrote a<br>
>> VBTableBuilder in the middle of CGVTables and it's so much simpler to<br>
>> connect with CodeGen than what I'm doing in VTableBuilder.h for<br>
>> vftables...<br>
>><br>
>> I believe this should all be available through just one interface<br>
>> (CGVTables?) which should have different implementations like<br>
>> ItaniumABIVTables (with VTT) and MicrosoftABIVTables (with VBTables)<br>
>> to be used from ItaniumCXXABI / MicrosoftCXXABI respectively.<br>
>> This way, we'll consolidate the V{,F,B}Tables-related code from at<br>
>> least three different places to just one.<br>
>> This interface should also provide methods deal with virtual calls as<br>
>> they slightly differ in these ABIs as well and tied to the vtables.<br>
>> What do you think about this general direction?<br>
>><br>
>> Would you mind if I move AST/VTableBuilder into CodeGen as the first step?<br>
<span class="HOEnZb"><font color="#888888">>><br>
>> --<br>
>> Timur Iskhodzhanov,<br>
>> Google Russia.<br>
><br>
</font></span></blockquote></div><br></div>