[LLVMdev] Struct layout assumptions
Talin
viridia at gmail.com
Sun Mar 2 12:47:59 PST 2008
A question about the layout of structs: I decided to make my vtables out
of structs rather than arrays. In other words, instead of being a table
of opaque pointers, I decided to individually declare each entry with
the correct type for that method. I figure that the various optimizers
could do a better job if I preserve the type info.
OK, so we come to the issue of inheritance: Suppose I have a class A and
subclass B, each of which have two methods.
One way to layout the vtable for B is to include the vtable for A as a
sub-structure, i.e.:
A.vtable = { A.method1 *, A.method2 * }
B.vtable = { { A.method1 *, A.method2 * }, B.method1 *, B.method2 * }
The advantage of this form is that when you upcast B to an A, the
pointer to the B vtable can be upcast as well - i.e. its a valid pointer
to a B vtable is also a valid pointer to an A vtable.
However, when it comes to actually calling methods this form is somewhat
cumbersome to work with. It means that each member in B can't simply
record a member index of which table entry it corresponds to; Instead it
has to record the entire set of GEP indices to get to that table entry.
A more convenient form is to simply flatten the structure:
A.vtable = { A.method1 *, A.method2 * }
B.vtable = { A.method1 *, A.method2 *, B.method1 *, B.method2 * }
Now each member can be referred to via a simple integer index.
However, the problem here is that I don't know if its legal to bitcast
from B.vtable to A.vtable. As far as I know, the optimizer might
re-order the member fields, or muck with the padding.
What sort of invariants can I rely on in this case?
-- Talin
More information about the llvm-dev
mailing list