I think the vftable layout code is getting pretty complicated. What do you
think about rewriting it with a more complete understanding of what vftables
need?
I sat down with David Majnemer to try to figure out what all goes into a
given vftable slot, and we came up with five offset-like things:
- The adjustment that the method will do in the prologue. This is the
negation of the vfptr offset in the class defining the method.
- The static this adjustment done in the thunk. This is the difference
between the offset of the vfptr containing the thunk and the adjustment done in
the prologue.
- The vtordisp offset. This is the offset from the vfptr to the containing
vbase minus four.
- The containing vbase, which is only present for vtordispex thunks. This is
used for vbtable lookup. Equivalently, this is the vbtable index or offset.
- The offset from the vbase containing the vfptr to the vbptr in the complete
type. This is used to power the vbtable lookup.
We don't capture this with our current data structures, but I imagine we
could simplify the code a lot if we did.
================
Comment at: test/CodeGenCXX/microsoft-abi-vtables-virtual-inheritance.cpp:459
@@ +458,3 @@
+namespace Test12 {
+struct X : B, A { };
+
----------------
Going forward, I'd really prefer it if our inheritance hierarchy tests could
all be standalone. See the microsoft-abi-vbtables.cpp test cases, where the
contents of any namespace can be cut-and-paste into a standalone .cpp file and
compiled.
In this test, I have to go lookup ::A and ::B in the right namespace to figure
out what kind of record this is going to be. It's worth a few lines of
duplicated test code to avoid that.
http://reviews.llvm.org/D3410
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
