Details
- Reviewers
rnk
Diff Detail
Event Timeline
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.
test/CodeGenCXX/microsoft-abi-vtables-virtual-inheritance.cpp | ||
---|---|---|
459 | 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. |
lgtm
I haven't been able to fully convince myself that the math is correct, but it does simplify the code and eliminate special cases. I still think we have a rewrite in the very near future, but this will be an easier reference to work from.
r206504, thanks!
We might indeed consider to refactor the code when we have better test coverage and better understanding of the corner cases.
I'll consider simplifying the tests in a separate commit.
2014-04-18 1:38 GMT+04:00 Reid Kleckner <rnk@google.com>:
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.
Like r206614?
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.