This is the mail archive of the
mailing list for the GCC project.
Re: [wide-int] Make trees more like rtxes
- 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: mikestump at comcast dot net, gcc-patches at gcc dot gnu dot org
- Date: Wed, 23 Oct 2013 08:21:14 -0400
- 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> <87eh7cqjsf dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <alpine dot LNX dot 2 dot 00 dot 1310231411580 dot 11149 at zhemvz dot fhfr dot qr>
On 10/23/2013 08:13 AM, Richard Biener wrote:
the wide_int_to_tree really needs to canonicalize the value before
making it into a tree.
the calls to tree_fits*_p (the successor to host_integer_p) depend on
this being clean.
Otherwise, these functions will have to clean the short integers and
they get called all over the place.
On Wed, 23 Oct 2013, Richard Sandiford wrote:
Richard Biener <firstname.lastname@example.org> writes:
The patch does that by adding:
for when we want to extend tree t to addr_wide_int precision and:
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
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.
Yes, I was looking at the matched interpret variant though to see
what we do.
AIUI it's used for VIEW_CONVERT_EXPRs, so I thought the upper bits
might get used.
Yeah, that might happen, but still relying on the upper bits in any
way would be brittle here.