Re: wide-int branch now up for public comment and review

[Richard Biener <rguenther at suse dot de>]

On Thu, 29 Aug 2013, Mike Stump wrote:

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

 struct GTY((variable_size)) hwivec_def {
-  int num_elem;		/* number of elements */
   HOST_WIDE_INT elem[1];
 };

no need to wrap this in an extra struct type.  In fact you can
re-use the hwint member and its accessors in

  union u {
    rtunion fld[1];
    HOST_WIDE_INT hwint[1];
    struct block_symbol block_sym;
    struct real_value rv;
    struct fixed_value fv;
  } GTY ((special ("rtx_def"), desc ("GET_CODE (&%0)"))) u;

Richard.