empty base packing strategy

[Jason Merrill]

>>>>> Jim Dehnert <dehnert at baalbek.engr.sgi.com> writes:

 >> Date: Thu, 15 Jul 1999 04:04:57 -0700
 >> From: Jason Merrill <jason at cygnus.com>
 >> 
 >> Say we have an A subobject, AO, followed by a B subobject.  If A ends with
 >> an empty class subjobject and B begins with an object of the same type, add
 >> 1 to the size of AO for layout purposes.

 > Perhaps I'm coming into the middle of something with context from the
 > meetings I missed, but this seems like a confusing way to look at this.
 > First, A should have a well-defined size

A does have a well-defined size.  Actually, it has two well-defined sizes;
one with padding (i.e. 1) and one without (i.e. 0).  Really, the empty base
optimization is a corner case of the tail padding optimization, with the
additional constraint of avoiding overlap.

The g++ implementation is to give a subobject the unpadded size of its type
unless that would lead to overlap, in which case it gets the padded size
(1).  But you don't have to set the offsets this way; using field sizes to
do this just seemed like a clean way to do it in gcc, since the backend
only knows about C structs.  My understanding is that the SGI compiler also
uses pseudo-fields for base subobjects.

 > and second, it leads to
 > questions about how to handle more general cases.  Consider Daveed's
 > earlier example:

 >         struct E1 { };
 >         struct E2: E1 { };
 >         struct E3 { };
 >         struct E4: E3 { };
 >         struct N1 { E1 n1; }

 >         struct D: E1, E2, N1, E3, E4 {
 >           E3 e3;
 >         };

My algorithm would do this:

E1: offset 0
E2: offset 1 (E1o has size 1 due to overlap)
N1: offset 2 (E2o has size 1 due to overlap)
E3: offset 2 (N1 has size 0)
E4: offset 3 (E3o has size 1)
e3: offset 4 (E4o has size 1)

So D has (unpadded) size 5.  Certainly it is possible to do better by
reordering, as you suggest doing; I don't feel strongly one way or the
other.  My approach is simpler; yours is more efficient.

If I were to implement your strategy, I would probably keep the current
code and just reorder the pseudo-fields as necessary.

Jason