[PATCH] Follow-up to r206457 -- fix static adjustments for some subtle virtual inheritance cases

[Reid Kleckner]

  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