[Bug c++/31176] reorder class data members to minimize space waste

[Bug c++/31176] reorder class data members to minimize space waste

[richard-gccbugzilla at metafoo dot co.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176

Richard Smith <richard-gccbugzilla at metafoo dot co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |richard-gccbugzilla@metafoo
                   |                            |.co.uk

--- Comment #10 from Richard Smith <richard-gccbugzilla at metafoo dot co.uk> ---
This reordering is no longer permitted. In C++11 onwards, only members with
different access levels (that is, public versus private) can be reordered.
Members with different access qualifier labels can no longer be reordered.

[Bug c++/31176] New: reorder class data members to minimize space waste

[sebor at roguewave dot com]

While discussing how today's C++ compilers lay out data members of structs and
classes on the C++ committee's mailing list the observation was made that no
known implementation, including gcc, takes advantage of the permission to
rearrange members declared with their own access specifier (see
c++std-core-11977). For example, the data members of the following struct are
laid out in declaration order even though a more space efficient order is
possible:

    struct S { public: char c; public: int i; public: char d; };

This problem is especially hard to solve in template code where the sizes of
one or more data members are not known, such as:

    template <class T, class U, class V>
    struct Triple { public: T a; public: U b; public: V c; };

Since reordering of existing structs would introduce a binary incompatibility I
would like to propose that a mechanism be provided whereby authors of new code
can mark up their types and/or data members in order to permit the compiler to
rearrange them in a space efficient manner, until gcc implements a new ABI
where the reordering algorithm becomes the default.

For example, a new type and/or variable attribute could be added (call it
reorder), that could be used to mark up types and/or data members to
participate in the reordering. To allow the compiler to arrange Triple members
in an efficient way the template would be marked up as follows:

    template <class T, class U, class V>
    struct Triple __attribute__ ((reorder)) {
       public: T a; public: U b; public: V c;
    };

or, alternatively, like so:

    template <class T, class U, class V>
    struct Triple {
       public: T a __attribute__ ((reorder));
       public: U b __attribute__ ((reorder));
       public: V c __attribute__ ((reorder));
    };

The order of members declared in the same section (introduced and closed by an
access specifier) without the attribute would not participate in the reordering
with one another.

Members of reordered aggregates would be initialized in declaration order.


-- 
           Summary: reorder class data members to minimize space waste
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sebor at roguewave dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176

[Bug c++/31176] reorder class data members to minimize space waste

[fang at csl dot cornell dot edu]

------- Comment #1 from fang at csl dot cornell dot edu  2007-03-14 18:14 -------
Interesting.  Do the attributes apply to derived classes automatically?  

struct B __attribute__((reorder)) {
char a;
int b;
};

struct D : public B {
char c, d, e;
};

Is D also allowed to reorder members a and b? even with an explicit
__attribute__((reorder))?
Would this break static_cast-ing from D to B due to change in layout?

D d;
int x = static_cast<const B&>(d).b; // how does this work if D's layout is not
a mere extension?

This might warrant a diagnostic saying this might not do what is expected. 
(What DOES one expect?)

Fang


-- 

fang at csl dot cornell dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fang at csl dot cornell dot
                   |                            |edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176

[Bug c++/31176] reorder class data members to minimize space waste

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2007-03-14 18:16 -------
Note actually some compilers actually do this even without an attribute.  This
is related to the art hack.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176

[Bug c++/31176] reorder class data members to minimize space waste

[sebor at roguewave dot com]

------- Comment #3 from sebor at roguewave dot com  2007-03-14 19:04 -------
(In reply to comment #1)
> Interesting.  Do the attributes apply to derived classes automatically?  

I would say no.

> 
[...]
> Is D also allowed to reorder members a and b? even with an explicit
> __attribute__((reorder))?

I'm afraid I don't know enough to give an informed answer but my gut tells me
that it might be safer to have the programmer explicitly ask for the base class
padding to be used to store members of the derived class (e.g., via some
creative application of the attribute in the definition of the derived class)
rather than having the compiler do it automatically for them.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176

[Bug c++/31176] reorder class data members to minimize space waste

[sebor at roguewave dot com]

------- Comment #4 from sebor at roguewave dot com  2007-03-14 19:05 -------
(In reply to comment #2)
> Note actually some compilers actually do this even without an attribute.  This
> is related to the art hack.

Out of curiosity, which compiler does it? And what's the art hack?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176

[Bug c++/31176] reorder class data members to minimize space waste

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2007-03-14 19:08 -------
(In reply to comment #4)
> Out of curiosity, which compiler does it? 
Sun and Intel (and I think IBM's also)

> And what's the art hack?

The art hack is when changing array of structs to struct of arrays.  The reason
why it is called the art hack is because it helps the art benchmark inside SPEC
2000.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176

[Bug c++/31176] reorder class data members to minimize space waste

[sebor at roguewave dot com]

------- Comment #6 from sebor at roguewave dot com  2007-03-15 19:54 -------
(In reply to comment #5)

I've checked all three but none of them seems to achieve an optimal layout in a
modified template case. Let me attach my test program.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176

[Bug c++/31176] reorder class data members to minimize space waste

[sebor at roguewave dot com]

------- Comment #7 from sebor at roguewave dot com  2007-03-15 19:55 -------
Created an attachment (id=13212)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13212&action=view)
test case for data member reordering


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176

[Bug c++/31176] reorder class data members to minimize space waste

[sebor at roguewave dot com]

------- Comment #8 from sebor at roguewave dot com  2007-03-15 23:51 -------
Some additional comments on the request precipitated by a discussion with the
implementers of another compiler:

The rationale for allowing the attribute on individual members is to provide 
fine-grained control over which members the compiler should be allowed to 
reorder and which it shouldn't.

For instance, I might want to define an aggregate struct that's optimally laid
out for space except for the first member which needs to be aligned at a
specific boundary:

  template <class T, class U>
  struct S __attribute ((aligned (16))) {
          size_t refcount;
  public: T      first __attribute ((reorder));
  public: U      second __attribute ((reorder));
  };

I know I could put T and U in a nested struct but I shouldn't need to do that.

Btw., since today's compiles are allowed to reorder first and second (but not
refcount), I think it's important that the the __attribute ((reorder)) be
considered in conjunction with the access specifier(s) so that when the
compiler implements reordering by default (i.e., w/o the attribute), the layout
of structs with members marked up with the attribute will stay the same even
after removing it. I.e., when gcc 5 comes out in 201X, it would be useful if
struct S below were laid out exactly the same as the struct S above generated
by gcc 4:

  template <class T, class U>
  struct S __attribute ((aligned (16)) {
          size_t refcount;
  public: T      first;    // no attribute
  public: U      second;   // no attribute
  };

Declaring S members with __attribute((reorder)) but without the access
specifiers otherwise necessary to allow the members to be reordered should have
no effect and give a diagnostic (warning or remark):

  template <class T, class U>
  struct S __attribute ((aligned (16)) {
      size_t refcount;
  public:
      T first __attribute ((reorder));
      U second __attribute ((reorder));
  };

Ditto if only first or only second (and not both) had an access specifier. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176

[Bug c++/31176] reorder class data members to minimize space waste

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2007-04-28 01:37 -------
I think this needs a real specifications and not just saying the reording can
happen (as an asside there are two kinds of derived types in Fortran, one
called sequence and the other normal, the sequence one is what C/C++ does by
default and the normal one is more like what you want as reordering).


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-04-28 01:37:23
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176