This is the mail archive of the gcc-patches@gcc.gnu.org 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] |
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.
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] |