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

*From*: Kenneth Zadeck <zadeck at naturalbridge dot com>*To*: Richard Biener <rguenther at suse dot de>, Richard Sandiford <rsandifo at linux dot vnet dot ibm dot com>*Cc*: gcc-patches at gcc dot gnu dot org, Mike Stump <mikestump at comcast dot net>*Date*: Thu, 17 Oct 2013 08:41:32 -0400*Subject*: Re: [wide-int] int_traits <tree>*Authentication-results*: sourceware.org; auth=none*References*: <alpine dot LNX dot 2 dot 00 dot 1310161537220 dot 11149 at zhemvz dot fhfr dot qr> <525EB50F dot 2090003 at naturalbridge dot com> <87ppr56on1 dot fsf at talisman dot default> <525EFC33 dot 4010304 at naturalbridge dot com> <87hacg720z dot fsf at talisman dot default> <alpine dot LNX dot 2 dot 00 dot 1310171015000 dot 11149 at zhemvz dot fhfr dot qr> <87k3hc9n9w dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <alpine dot LNX dot 2 dot 00 dot 1310171309390 dot 11149 at zhemvz dot fhfr dot qr> <87bo2o9kow dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <alpine dot LNX dot 2 dot 00 dot 1310171406490 dot 11149 at zhemvz dot fhfr dot qr>

On 10/17/2013 08:29 AM, Richard Biener wrote:

On Thu, 17 Oct 2013, Richard Sandiford wrote:Richard Biener <rguenther@suse.de> writes:The new tree representation can have a length greater than max_len for an unsigned tree constant that occupies a whole number of HWIs. The tree representation of an unsigned 0x8000 is 0x00 0x80 0x00. When extended to max_wide_int the representation is the same. But a 2-HWI addr_wide_int would be 0x80 0x00, without the leading zero. The MIN trims the length from 3 to 2 in the last case.Oh, so it was the tree rep that changed? _Why_ was it changed? We still cannot use it directly from wide-int and the extra word is redundant because we have access to TYPE_UNSIGNED (TREE_TYPE ()).It means that we can now use the tree's HWI array directly, without any copying, for addr_wide_int and max_wide_int. The only part of decompose () that does a copy is the small_prec case, which is trivially compiled out for addr_wide_int and max_wide_int." 2) addr_wide_int. This is a fixed size representation that is guaranteed to be large enough to compute any bit or byte sized address calculation on the target. Currently the value is 64 + 4 bits rounded up to the next number even multiple of HOST_BITS_PER_WIDE_INT (but this can be changed when the first port needs more than 64 bits for the size of a pointer). This flavor can be used for all address math on the target. In this representation, the values are sign or zero extended based on their input types to the internal precision. All math is done in this precision and then the values are truncated to fit in the result type. Unlike most gimple or rtl intermediate code, it is not useful to perform the address arithmetic at the same precision in which the operands are represented because there has been no effort by the front ends to convert most addressing arithmetic to canonical types. In the addr_wide_int, all numbers are represented as signed numbers. There are enough bits in the internal representation so that no infomation is lost by representing them this way." so I guess from that that addr_wide_int.get_precision is always that "64 + 4 rounded up". Thus decompose gets that constant precision input and the extra zeros make the necessary extension always a no-op. Aha.

For max_wide_int the same rules apply, just its size is larger. Ok. So the reps are only canonical wide-int because we only ever use them with precision > xprecision (maybe we should assert that).

It is now asserted for (as of a few days ago).

Btw, we are not using them directly, but every time we actually build a addr_wide_int / max_wide_int we copy them anyway: /* Initialize the storage from integer X, in precision N. */ template <int N> template <typename T> inline fixed_wide_int_storage <N>::fixed_wide_int_storage (const T &x) { /* Check for type compatibility. We don't want to initialize a fixed-width integer from something like a wide_int. */ WI_BINARY_RESULT (T, FIXED_WIDE_INT (N)) *assertion ATTRIBUTE_UNUSED; wide_int_ref xi (x, N); len = xi.len; for (unsigned int i = 0; i < len; ++i) val[i] = xi.val[i]; }

it avoids a 2nd copy though, which shows nicely what was rummaging in my head for the last two days - that the int_trais <> abstraction was somehow at the wrong level - it should have been traits that are specific to the storage model? or the above should use int_traits<>::decompose manually with it always doing the copy (that would also optimize away one copy and eventually would make the extra zeros not necessary).

I originally thought that extra zeros get rid of all copying from trees to all wide-int kinds. What's the reason again to not use my original proposed encoding of the MSB being the sign bit? RTL constants simply are all signed then. Just you have to also sign-extend in functions like lts_p as not all constants are sign-extended. But we can use both tree (with the now appended zero) and RTL constants representation unchanged.

**Follow-Ups**:**Re: [wide-int] int_traits <tree>***From:*Richard Biener

**Re: [wide-int] int_traits <tree>***From:*Richard Sandiford

**References**:**[wide-int] int_traits <tree>***From:*Richard Biener

**Re: [wide-int] int_traits <tree>***From:*Kenneth Zadeck

**Re: [wide-int] int_traits <tree>***From:*Richard Sandiford

**Re: [wide-int] int_traits <tree>***From:*Kenneth Zadeck

**Re: [wide-int] int_traits <tree>***From:*Richard Sandiford

**Re: [wide-int] int_traits <tree>***From:*Richard Biener

**Re: [wide-int] int_traits <tree>***From:*Richard Sandiford

**Re: [wide-int] int_traits <tree>***From:*Richard Biener

**Re: [wide-int] int_traits <tree>***From:*Richard Sandiford

**Re: [wide-int] int_traits <tree>***From:*Richard Biener

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |