On Wed, 28 Aug 2013, Mike Stump wrote:
> On Aug 28, 2013, at 3:22 AM, Richard Biener <rguent...@suse.de> wrote:
> > Btw, rtl.h still wastes space with
> >
> > struct GTY((variable_size)) hwivec_def {
> > int num_elem; /* number of elements */
> > HOST_WIDE_INT elem[1];
> > };
> >
> > struct GTY((chain_next ("RTX_NEXT (&%h)"),
> > chain_prev ("RTX_PREV (&%h)"), variable_size)) rtx_def {
> > ...
> > /* The first element of the operands of this rtx.
> > The number of operands and their types are controlled
> > by the `code' field, according to rtl.def. */
> > union u {
> > rtunion fld[1];
> > HOST_WIDE_INT hwint[1];
> > struct block_symbol block_sym;
> > struct real_value rv;
> > struct fixed_value fv;
> > struct hwivec_def hwiv;
> > } GTY ((special ("rtx_def"), desc ("GET_CODE (&%0)"))) u;
> > };
> >
> > there are 32bits available before the union. If you don't use
> > those for num_elem then all wide-ints will at least take as
> > much space as DOUBLE_INTs originally took - and large ints
> > that would have required DOUBLE_INTs in the past will now
> > require more space than before. Which means your math
> > motivating the 'num_elem' encoding stuff is wrong. With
> > moving 'num_elem' before u you can even re-use the hwint
> > field in the union as the existing double-int code does
> > (which in fact could simply do the encoding trick in the
> > old CONST_DOUBLE scheme, similar for the tree INTEGER_CST
> > container).
>
> So, HOST_WIDE_INT is likely 64 bits, and likely is 64 bit aligned. The
> base (stuff before the union) is 32 bits. There is a 32 bit gap, even
> if not used before the HOST_WIDE_INT elem. We place the num_elem is
> this gap.
No, you don't. You place num_elem 64bit aligned _after_ the gap.
And you have another 32bit gap, as you say, before elem.
> Even if the field were removed, the size would not change,
> nor the placement of elem. So, short of packing, a 32-bit HWI host or
> going with a 32-bit type instead of a HOST_WIDE_INT, I'm not sure I
> follow you? I tend to discount 32-bit hosted compilers as a thing of
> the past.
Me, too. On 32bit hosts nothing would change as 'u' is 32bit aligned
there (ok, on 32bit hosts putting num_elem before 'u' would actually
increase memory usage - but as you say, 32bit hosted compilers are
a thing of the past ;)).
Richard.
