This is the mail archive of the gcc-patches@gcc.gnu.org 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>


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).

Thanks,
Richard


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