Commit Message

On Aug 29, 2013, at 12:36 AM, Richard Biener <rguenther@suse.de> wrote:
> On Wed, 28 Aug 2013, Mike Stump wrote:> >> On Aug 28, 2013, at 3:22 AM, Richard Biener <rguenther@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.
Ah, ok, I get it, thanks for the explanation. This removes the second gap creator and puts the field into the gap before the u union.