Tail padding, again

[Jim Dehnert]

> From: Mark Mitchell <mark at codesourcery.com>
> 
> I think I recall that the committee was intentionally trying to use
> the tail padding of one object to save space.  For example, consider:
> 
>   struct A { short s; char c; };
>   struct B { A a; char d; };
> 
> (These are PODs, but you can easily make an equivalent non-POD example).
> 
> Here, I think the comittee wanted to give `B' size 4, by packing `d'
> into the tail padding of `A'.

The committee was also _very_ interested in using the tail padding, and
examples were provided that I thought were fairly convincing.  Backing
out of this at this time would cause various people a fair amount of
trouble, I think.

> I think this is a mistake.  David Gross came up with the following
> example:
> 
>   - Code generator needs to copy dsize, not sizeof, unless it can prove
>     that the object is in a context where tail padding isn't overlayed.
>     Reason?  Tail padding might be overlayed by a volatile field.
> 
>     Hence, a non-POD that looks like
> 
>       struct S { short sh; char ch; };
> 
>     requires ld2/st2/ld1/st1 for a copy instead of ld4/st4 because we
>     might have
> 
>       struct T { S s; volatile char d; };

If overlaying by a volatile field is the problem, I'd prefer to make an
exception for it.  But is it really?  There are two "kinds" of
volatiles (to generalize about a very poorly defined concept), based on
usage.  There are those declared volatile because they map hardware
features that can't tolerate extra loads/stores -- these are the real
issue, and I don't know if they end up in definitions that might be
overlaid -- I doubt it.  The others are declared volatile because the
user doesn't want their references moved/omitted, e.g. for locking
purposes, but an extra load due to a larger copy won't affect anything.
I don't feel strongly, but I could live with either forbidding
overlaying volatile members, or ignoring them.  I don't think we should
completely rearrange our layout at this point.

> Similarly, people using memcpy to copy around POD components of
> non-PODs will get burned.

No, we explicitly say for PODs that size=nvsize (2.2).

> This completely breaks user expectation since people routinely expect
> to be able to stick a function or two into a POD without changing its
> layout.
> 
> I think we should make the following changes:
> 
>   - Make nvsize a multiple of nvalign.  That ensures that we don't
>     have odd sub-components that we can't copy around easily.
> 
>   - Allocate `sizeof' bytes for a data member, and `nvsize' bytes for
>     a base class when laying out an object.
> 
> Note that this still permits the empty base optimization; nvsize will
> be zero, and sizeof will be 1.
> 
> There's an important different between using the tail padding in an
> empty base and the tail padding in a generic object: you know that you
> never have to copy an empty base.

But copying padding isn't supposed to matter.

JIm

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272