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

[John McCall]

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". :)

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.

Also, if you'd like to implement the MS ABI methods that we've already
extracted out, that would be awesome.

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?  There are two
important use cases for these structures — emitting a reference and emitting
the actual tables.  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, or whether multiple vftables are emitted in the same
global as each other.

> - 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.

> - 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.

We'll also need some hook to override the default calling convention for
instance methods.

> - 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.

> 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.

John.