[wide-int] int_traits <tree>

Richard Biener rguenther@suse.de
Thu Oct 17 14:50:00 GMT 2013

On Thu, 17 Oct 2013, Richard Sandiford wrote:

> Richard Biener <rguenther@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.


More information about the Gcc-patches mailing list