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. 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.
