This is the mail archive of the 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]

Re: [wide-int] int_traits <tree>

On Thu, 17 Oct 2013, Kenneth Zadeck wrote:

> On 10/17/2013 10:05 AM, Richard Sandiford wrote:
> > Richard Biener <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]