This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Aug 29, 2013, at 12:36 AM, Richard Biener <> wrote:
> On Wed, 28 Aug 2013, Mike Stump wrote:
>> On Aug 28, 2013, at 3:22 AM, Richard Biener <> 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.

Attachment: p.diffs.txt
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]