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] |

*From*: Richard Sandiford <rsandifo at linux dot vnet dot ibm dot com>*To*: Richard Biener <rguenther at suse dot de>*Cc*: Kenneth Zadeck <zadeck at naturalbridge dot com>, gcc-patches at gcc dot gnu dot org, Mike Stump <mikestump at comcast dot net>*Date*: Thu, 17 Oct 2013 15:05:03 +0100*Subject*: Re: [wide-int] int_traits <tree>*Authentication-results*: sourceware.org; auth=none*References*: <alpine dot LNX dot 2 dot 00 dot 1310161537220 dot 11149 at zhemvz dot fhfr dot qr> <525EB50F dot 2090003 at naturalbridge dot com> <87ppr56on1 dot fsf at talisman dot default> <525EFC33 dot 4010304 at naturalbridge dot com> <87hacg720z dot fsf at talisman dot default> <alpine dot LNX dot 2 dot 00 dot 1310171015000 dot 11149 at zhemvz dot fhfr dot qr> <87k3hc9n9w dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <alpine dot LNX dot 2 dot 00 dot 1310171309390 dot 11149 at zhemvz dot fhfr dot qr> <87bo2o9kow dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <alpine dot LNX dot 2 dot 00 dot 1310171406490 dot 11149 at zhemvz dot fhfr dot qr> <877gdc9fxb dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <alpine dot LNX dot 2 dot 00 dot 1310171542090 dot 11149 at zhemvz dot fhfr dot qr>

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

**Follow-Ups**:**Re: [wide-int] int_traits <tree>***From:*Richard Biener

**Re: [wide-int] int_traits <tree>***From:*Kenneth Zadeck

**References**:**[wide-int] int_traits <tree>***From:*Richard Biener

**Re: [wide-int] int_traits <tree>***From:*Kenneth Zadeck

**Re: [wide-int] int_traits <tree>***From:*Richard Sandiford

**Re: [wide-int] int_traits <tree>***From:*Kenneth Zadeck

**Re: [wide-int] int_traits <tree>***From:*Richard Sandiford

**Re: [wide-int] int_traits <tree>***From:*Richard Biener

**Re: [wide-int] int_traits <tree>***From:*Richard Sandiford

**Re: [wide-int] int_traits <tree>***From:*Richard Biener

**Re: [wide-int] int_traits <tree>***From:*Richard Sandiford

**Re: [wide-int] int_traits <tree>***From:*Richard Biener

**Re: [wide-int] int_traits <tree>***From:*Richard Sandiford

**Re: [wide-int] int_traits <tree>***From:*Richard Biener

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |