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