This is the mail archive of the
mailing list for the GCC project.
Re: [wide-int] Make trees more like rtxes
- From: Richard Sandiford <rsandifo at linux dot vnet dot ibm dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: zadeck at naturalbridge dot com, mikestump at comcast dot net, gcc-patches at gcc dot gnu dot org
- Date: Wed, 23 Oct 2013 13:00:16 +0100
- Subject: Re: [wide-int] Make trees more like rtxes
- Authentication-results: sourceware.org; auth=none
- References: <87txg9cvzc dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <alpine dot LNX dot 2 dot 00 dot 1310231057260 dot 11149 at zhemvz dot fhfr dot qr>
Richard Biener <firstname.lastname@example.org> writes:
>> The patch does that by adding:
>> wi::address (t)
>> for when we want to extend tree t to addr_wide_int precision and:
>> wi::extend (t)
>> for when we want to extend it to max_wide_int precision. (Better names
>> welcome.) These act just like addr_wide_int (t) and max_wide_int (t)
>> would on current sources, except that they use the tree representation
>> directly, so there's no copying.
> Good. Better names - ah well, wi::to_max_wide_int (t) and
> wi::to_addr_wide_int (t)? Btw, "addr_wide_int" is an odd name as it
> has at least the precision of the maximum _bit_ offset possible, right?
> So more like [bit_]offset_wide_int? Or just [bit_]offset_int?
> And then wi::to_offset (t) and wi::to_max (t)?
offset_int, max_int, wi::to_offset and wi::to_max sound OK to me.
>> Most of the patch is mechanical and many of the "wi::address (...)"s
>> and "wi::extend (...)"s reinstate "addr_wide_int (...)"s and
>> "max_wide_int (...)"s from the initial implementation. Sorry for the
>> run-around on this.
>> One change I'd like to point out though is:
>> @@ -7287,7 +7287,9 @@ native_encode_int (const_tree expr, unsi
>> for (byte = 0; byte < total_bytes; byte++)
>> int bitpos = byte * BITS_PER_UNIT;
>> - value = wi::extract_uhwi (expr, bitpos, BITS_PER_UNIT);
>> + /* Extend EXPR according to TYPE_SIGN if the precision isn't a whole
>> + number of bytes. */
>> + value = wi::extract_uhwi (wi::extend (expr), bitpos, BITS_PER_UNIT);
>> if (total_bytes > UNITS_PER_WORD)
>> I think this preserves the existing trunk behaviour but I wasn't sure
>> whether it was supposed to work like that or whether upper bits should
>> be zero.
> I think the upper bits are undefined, the trunk native_interpret_int
> result = double_int::from_buffer (ptr, total_bytes);
> return double_int_to_tree (type, result);
> where the call to double_int_to_tree re-extends according to the types
> precision and sign. wide_int_to_tree doesn't though?
This is native_encode_int rather than native_interpret_int though.
AIUI it's used for VIEW_CONVERT_EXPRs, so I thought the upper bits
might get used.