<div dir="ltr">Timur,<div><br></div><div style>I have no information that I can share on PathScale's current activities.  I have copied in Christopher Bergstrom who may be able to provide more information.</div><div style>
<br></div><div style>I would say though that the process of moving the vtable builder to AST was a huge pain and it would be good if nobody else would have to go through it.</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>