[cfe-dev] RFC: Flesh out the IRGen C++ ABI class

[Charles Davis]

On 10/25/10 2:34 AM, John McCall wrote:
> On Oct 23, 2010, at 6:59 PM, Charles Davis wrote:
>> Well, it's been awhile, but I finally got around to finishing up
>> libCodeGen's C++ ABI class. I've added a few methods in this patch to:
> 
> I wouldn't say "finished". :)
'Course not. I have a long way to go. I'm just saying that I'm going to
finish this up now.
> 
> It's great to hear that you're planning on working on implementing these
> features for different ABIs!  That said, I don't really see much value in
> fleshing out the API so far in advance of any implementations;  it's not
> like the eventual API is likely to match the current idea.  Please introduce
> these methods only as you generalize the features behind them.
OK. I just wanted to know your opinion on what I had in mind.
> 
> Also, if you'd like to implement the MS ABI methods that we've already
> extracted out, that would be awesome.
All right then.
> 
> I'll go ahead and comment on the interfaces you've proposed;  feel free
> to ignore these comments until you get around to those features.
> 
>> - Emit important C++ data structures (RTTI descriptors, virtual tables)
> 
> When are these methods called and what do they return?
LayoutVTables() and EmitRTTIDescriptors(). They both return an
llvm::Value*. In retrospect, returning only one value seems limited. The
methods' names imply that there could be more than one.
>  There are two
> important use cases for these structures — emitting a reference and emitting
> the actual tables.
Right--which means I'm missing some methods.
>  Also, v-tables can involve multiple GlobalValues even in the
> Itanium ABI, and I don't know whether the MSVC ABI emits vbtables in the
> same global as vftables,
Probably not. There are two different manglings for them.
> or whether multiple vftables are emitted in the same
> global as each other.
Nope, unless the class was declared __declspec(selectany), in which case
the vftable gets emitted as a SELECT_ANY COMDAT, and the linker will
then coalesce identical vftables into one. But the coalescing happens
after the compiler has finished running, so that's no help.
> 
>> - Retrieve the CGRecordLayoutBuilder, which can be overridden by the ABI.
> 
> How are you expecting this to work?  CGRecordLayoutBuilder is not currently
> a singleton, and I'm pretty sure multiple layouts can be in-flight at once.
Good point. I should probably have it return *a* CGRecordLayoutBuilder
instead. I could have it construct an instance of the object, and the
caller could supply any necessary parameters.
> 
>> - Emit a call to a virtual method.
> 
> Hmm.  I'd prefer a method more like EmitLoadOfMemberFunctionPointer,
> which returns the function to call and adjusts the 'this' pointer but doesn't
> actually call the function.
I considered that, but then I started thinking more generically. I can
easily envision an Objective-C-like C++ ABI that uses message sends
instead of vtables to implement virtual calls. But, since I already have
the LayOutVTables() method, that seems like a moot point. I'll change it
back for now.
> 
> We'll also need some hook to override the default calling convention for
> instance methods.
True. The Sema CXXABI object also needs one, by the way.
> 
>> - Emit loads and stores to fields in C++ classes/structs--particularly
>> important for fields in virtual bases.
> 
> Is this actually necessary?  The sub-expression on a MemberExpr should
> always be an l-value of the type which declared the field.  You should only
> need a hook to do a virtual derived-to-base conversion.
Yeah, you can tell I'm still pretty new to this. But your idea makes sense.

I was thinking of a C++ ABI that stored members--all members--in exotic
ways, like say, putting them in a separate struct and having a pointer
to that struct in the object proper, but I guess we could model that in
the AST.
> 
>> I haven't put in any EH-related stuff--I leave that in John's capable
>> hands, since he knows way more about it than I do. (Also, he told me
>> he'd do it, so that helps :).
> 
> Yeah, there's a lot of backend work still to be done here.
Thanks for the feedback!

Chip