On Wed, 23 Oct 2013, Richard Sandiford wrote:
> Richard Biener <rguent...@suse.de> 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.
> Kenny? Mike?
>
> >> 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
> > does
> >
> > 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.
Richard.
