On Thu, 17 Oct 2013, 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).
At least you can easily optimize for existing zero / sign extension. What I see is really bad code for the simple integer-cst predicates in tree.c. I don't mind in what way we fix it, but avoiding the copy on every tree integer constant read looks required to me. Richard.
