New g++ ABI

New g++ ABI

[Jason Merrill]

I've started working on a new ABI for g++, beginning with object layout.
First, I changed base allocation to generate FIELD_DECLs for each base
instead of one for all of them, for easier modification.  Then I
implemented the empty base optimization, conditional on -fnew-abi.
-fnew-abi also fixes a condition whereby bases got more padding than
fields.

Compiling without -fnew-abi should produce the same results as before;
please let me know if I accidentally changed something.

I'm thinking about reducing the padding on bases down below the padding
that fields get, so that the next base is allocated within the padding of
the previous one: i.e.

  struct A
  {
    int i;
    char c;
  };

  struct B
  {
    char c;
  };

  struct C
  {
    A a;
    B b;
    int c;
  }

  struct D : public A, public B
  {
    int c;
  };

Here, on a 32-bit target sizeof(A) is 8, and sizeof(B) is 1.  sizeof(C) is
16, because b has to be padded out to alignof (int).  But in D, we can
allocate B within the padding of A, so sizeof(D) is only 12.

Does anyone object to this optimization?  It breaks
memset (p, 0, sizeof (P)), but that isn't guaranteed to work, and
will break anyway for empty classes and classes with virtual bases.  But do
we want to break it for, say, C structs used as bases?

I'm also thinking about optimizing the implementation of virtual bases (and
fixing it so thunks work in g++.mike/p6610a.C).

Warning:  The ABI produced by -fnew-abi may vary from day to day.  Do not
expect prolonged binary compatibility until I say otherwise.

Jason

Re: New g++ ABI

[Joe Buck]

> I'm thinking about reducing the padding on bases down below the padding
> that fields get, so that the next base is allocated within the padding of
> the previous one: i.e. ...

> Does anyone object to this optimization?  It breaks
> memset (p, 0, sizeof (P)), but that isn't guaranteed to work, and
> will break anyway for empty classes and classes with virtual bases.  But do
> we want to break it for, say, C structs used as bases?

We have to watch out for things like compiler-generated copy constructors
and assignment operators, or STL allocators, doing the equivalent
operation (of writing sizeof(P) bytes though P is a baseclass.  If
we can guarantee that this doesn't happen we're probably OK.

> Warning:  The ABI produced by -fnew-abi may vary from day to day.  Do not
> expect prolonged binary compatibility until I say otherwise.

Depending on timing, it might be a good idea to try to combine all
the new features that may break compatibility, e.g. -fsquangle, into
-fnew-api.

Re: New g++ ABI

[Jason Merrill]

>>>>> Joe Buck <jbuck@Synopsys.COM> writes:

>> I'm thinking about reducing the padding on bases down below the padding
>> that fields get, so that the next base is allocated within the padding of
>> the previous one: i.e. ...

>> Does anyone object to this optimization?  It breaks
>> memset (p, 0, sizeof (P)), but that isn't guaranteed to work, and
>> will break anyway for empty classes and classes with virtual bases.  But do
>> we want to break it for, say, C structs used as bases?

> We have to watch out for things like compiler-generated copy constructors
> and assignment operators, or STL allocators, doing the equivalent
> operation (of writing sizeof(P) bytes though P is a baseclass.  If
> we can guarantee that this doesn't happen we're probably OK.

Good point.  I guess I'll just do this for classes that need to be copied
memberwise anyway.

>> Warning:  The ABI produced by -fnew-abi may vary from day to day.  Do not
>> expect prolonged binary compatibility until I say otherwise.

> Depending on timing, it might be a good idea to try to combine all
> the new features that may break compatibility, e.g. -fsquangle, into
> -fnew-api.

Will do.

Jason

Re: New g++ ABI

[Jason Merrill]

>>>>> Loren J Rittle <rittle@supra.rsch.comm.mot.com> writes:

> Stanley B. Lippman objects to your optimization in _Inside the C++
> Object Model_.  Another form of this optimization is discussed ppg. 85 - 87.

Hmm, perhaps I'll have to check that book out.

> I will adjust his example to your stated case:

> D *d;
> A *a, *b;

> *a = *b; // should perform a default memberwise copy of the A portion
> 	 // of the object addressed.  The compiler generated version
> 	 // might look like: memcpy (..., ..., sizeof (A));

Agreed.  I think I'll limit the optimization to classes with nontrivial
copy constructors and copy assignment operators, since they will be doing
true memberwise copies anyway.

> 	 // users are supposed to be able to define a memberwise
> 	 // copy the same way.

You mean C& operator=(const C& c) { memcpy (this, &c, sizeof (C)); } ?
I don't think so.  This is only guaranteed to work for POD types, and when
you define the copy assignment op, you no longer have a POD type.

> Assuming the issue Stanley raises may be completely worked around, why
> stop there?  To the logical conclusion, sizeof (C) and sizeof (D)
> could be 12 on a 32-bit target.

The size of a field is defined by C ABIs.  On the other hand, that doesn't
necessarily apply to classes with non-trivial copy semantics.  Hmm, I may
just do that.

> - If only the compiler generated memberwise copy and copy constructor
>   exist, then mark class definition to use packing as you specify.
>   Compiler must now track sizeof_before_padding () and sizeof ().  Any
>   compiler generated functions must now use sizeof_before_padding()
>   instead of sizeof().  Users that try tricky stuff with sizeof () may
>   still lose (even if it was legal C!).  Perhaps a warning could be
>   given to the user whenever sizeof() is applied to class marked to
>   allow the type of packing you propose and the compiler doesn't
>   recognize the use of the value of the sizeof operator as being
>   completely safe.

An interesting idea, but not all uses of sizeof are unsafe.  Only assuming
it is useful for a sub-object is unsafe, which is already true for classes
with virtual bases.

> - If our C/C++ compiler did a complete analysis of all user code
>   before generating the final executable image, then many new
>   optimizations would be available within application code (outside
>   code/data dealing with the OS and standard library interface points).

Agreed.  But we want to make the single translation unit optimizations
better first...

Jason

Re: New g++ ABI

[Joe Buck]

> > D *d;
> > A *a, *b;
> 
> > *a = *b; // should perform a default memberwise copy of the A portion
> > 	 // of the object addressed.  The compiler generated version
> > 	 // might look like: memcpy (..., ..., sizeof (A));
> 
> Agreed.  I think I'll limit the optimization to classes with nontrivial
> copy constructors and copy assignment operators, since they will be doing
> true memberwise copies anyway.

The optimization is also allowed for empty base classes, since presumably
the compiler-generated copy ctors and assign ops do nothing in that
case.