On Thu, 17 Oct 2013, Kenneth Zadeck wrote: > On 10/17/2013 10:05 AM, Richard Sandiford wrote: > > Richard Biener <rguent...@suse.de> 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. Richard.
