This is the mail archive of the
mailing list for the GCC project.
Re: [wide-int] int_traits <tree>
- From: Richard Biener <rguenther at suse dot de>
- To: Kenneth Zadeck <zadeck at naturalbridge dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Mike Stump <mikestump at comcast dot net>, rsandifo at linux dot vnet dot ibm dot com
- Date: Fri, 18 Oct 2013 10:48:46 +0200 (CEST)
- 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> <877gdc9fxb dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <alpine dot LNX dot 2 dot 00 dot 1310171542090 dot 11149 at zhemvz dot fhfr dot qr> <87vc0w8034 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <52601614 dot 3040009 at naturalbridge dot com>
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
> On 10/17/2013 10:05 AM, Richard Sandiford wrote:
> > Richard Biener <firstname.lastname@example.org> writes:
> > > > > 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.
> > > > The answer's the same as always. RTL constants don't have a sign.
> > > > Any time we extend an RTL constant, we need to say whether the extension
> > > > should be sign extension or zero extension. So the natural model for
> > > > RTL is that an SImode addition is done to SImode width, not some
> > > > arbitrary wider width.
> > > RTL constants are sign-extended (whether you call them then "signed"
> > > is up to you). They have a precision. This is how they are
> > > valid reps for wide-ints, and that doesn't change.
> > >
> > > I was saying that if we make not _all_ wide-ints sign-extended
> > > then we can use the tree rep as-is. We'd then have the wide-int
> > > rep being either zero or sign extended but not arbitrary random
> > > bits outside of the precision (same as the tree rep).
> > OK, but does that have any practical value over leaving them arbitrary,
> > as in Kenny's original implementation? Saying that upper bits can be
> > either signs or zeros means that readers wouldn't be able to rely on
> > one particular extension (so would have to do the work that they did
> > in Kenny's implementation). At the same time it means that writers
> > can't leave the upper bits in an arbitrary state, so would have to
> > make sure that they are signs or zeros (presumably having a free
> > choice of which).
> > Thanks,
> > Richard
> not so easy here. We would still need to clean things up when we convert
> back to tree-cst or rtl at least for the short precisions. Otherwise, the
Sure. But wide-int to tree / RTL is already expensive as we're going to
allocate memory and copy the rep anyway (and modify-on-copy makes the
modify part almost free I'd say).
> parts of the compiler that look inside of trees, in particular the hash
> functions have to clean the value them selves.
> As much as my arm still hurts from richi forcing me to change this, it is true
> that it seems to have been the right thing to do.
> the change for the wider unsigned trees perhaps should be backed out.
Yeah, I suppose we can avoid the 2nd copy for the fixed_wide_int
interface in other ways.