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 Biener <richard dot guenther at gmail dot com>*To*: Richard Biener <richard dot guenther at gmail dot com>, Kenneth Zadeck <zadeck at naturalbridge dot com>, Mike Stump <mikestump at comcast dot net>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Lawrence Crowl <crowl at google dot com>, Ian Lance Taylor <iant at google dot com>, rdsandiford at googlemail dot com*Date*: Wed, 24 Apr 2013 17:13:28 +0200*Subject*: Re: patch to fix constant math -5th patch, rtl*References*: <506C72C7 dot 7090207 at naturalbridge dot com> <CAFiYyc1=8=LffiZ=EDBOy_uzn_ARdXk1OWxT=abYd8ot+iFp5Q at mail dot gmail dot com> <50891AAC dot 8090301 at naturalbridge dot com> <CAFiYyc15kmhRWhN3tsZqJDbZ5Uh6tVa45ssiYdsytLEfqaZ4zw at mail dot gmail dot com> <87y5im3orb dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAFiYyc2buJtu8RMKnLnvvb-A2=aYwopO+RBLPO6iJ3gKnq-hvg at mail dot gmail dot com> <87pq3y3kyk dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAFiYyc3NjOxpQ-Y9GDrQOET+dc3LXWuiuM=DxqmyASE8urRoWw at mail dot gmail dot com> <50912D85 dot 1070002 at naturalbridge dot com> <CAFiYyc2Q2UQPmkhExi2c8f-BSGLv+Rq1rOy4NdPQmTqSRE1A0A at mail dot gmail dot com> <5091331C dot 3030504 at naturalbridge dot com> <CAFiYyc1L6zuehE75dEfd_fB1-81F1fDHpL3kS=tbk6qAK3Texg at mail dot gmail dot com> <512D686B dot 90000 at naturalbridge dot com> <515EC4E7 dot 7040907 at naturalbridge dot com> <CAFiYyc3P8sFfFQT95yr_UZSOs-JOUefvCm0bxQe1ZSUDgcMg_A at mail dot gmail dot com> <871ua0qer8 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAFiYyc2kotJXQKT8sWu7UXKd5bYccpZKegMajRSt6BesAx-=ZA at mail dot gmail dot com> <87y5c8nhz2 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAFiYyc15V9NDk2dAJ9kZZ8wwoxts7bEm5eA5Lk8Tk2Erk9LWKg at mail dot gmail dot com> <87fvygngsw dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAFiYyc0ufm=UFdxgesCxGVV5jO+V-4BJ5nJGLJP6mk8-Wqt=vQ at mail dot gmail dot com> <87txmwm0r9 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com>

On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford <rdsandiford@googlemail.com> wrote: > Richard Biener <richard.guenther@gmail.com> writes: >> On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford >> <rdsandiford@googlemail.com> wrote: >>> In other words, one of the reasons wide_int can't be exactly 1:1 >>> in practice is because it is clearing out these mistakes (GEN_INT >>> rather than gen_int_mode) and missing features (non-power-of-2 widths). >> >> Note that the argument should be about CONST_WIDE_INT here, >> not wide-int. Indeed CONST_WIDE_INT has the desired feature >> and can be properly truncated/extended according to mode at the time we build it >> via immed_wide_int_cst (w, mode). I don't see the requirement that >> wide-int itself is automagically providing that truncation/extension >> (though it is a possibility, one that does not match existing behavior of >> HWI for CONST_INT or double-int for CONST_DOUBLE). > > I agree it doesn't match the existing behaviour of HWI for CONST_INT or > double-int for CONST_DOUBLE, but I think that's very much a good thing. > The model for HWIs at the moment is that you have to truncate results > to the canonical form after every operation where it matters. As you > proved in your earlier message about the plus_constant bug, that's easily > forgotten. I don't think the rtl code is doing all CONST_INT arithmetic > on full HWIs because it wants to: it's doing it because that's the way > C/C++ arithmetic on primitive types works. In other words, the current > CONST_INT code is trying to emulate N-bit arithmetic (for gcc runtime N) > using a single primitive integer type. wide_int gives us N-bit arithmetic > directly; no emulation is needed. Ok, so what wide-int provides is integer values encoded in 'len' HWI words that fit in 'precision' or more bits (and often in less). wide-int also provides N-bit arithmetic operations. IMHO both are tied too closely together. A give constant doesn't really have a precision. Associating one with it to give a precision to an arithmetic operation looks wrong to me and are a source of mismatches. What RTL currently has looks better to me - operations have explicitely specified precisions. > If your point is that an arbitrary-precision wide_int could be used by > other (non-rtl, and probably non-tree) clients, then I don't really > see the need. We already have mpz_t for that. What we don't have, > and what we IMO need, is something that performs N-bit arithmetic > for runtime N. It seems better to have a single class that does > that for us (wide_int), rather than scatter N-bit emulation throughout > the codebase, which is what we do now. mpz_t is not suitable here - it's way too expensive. double-int was the "suitable" bit for now, but given it's host dependency and inability to handle larger ints (VRP ...) the ability to use wide-ints for this looks appealing. Richard. > Richard

**Follow-Ups**:**Re: patch to fix constant math -5th patch, rtl***From:*Richard Sandiford

**Re: patch to fix constant math -5th patch, rtl***From:*Kenneth Zadeck

**References**:**Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1***From:*Kenneth Zadeck

**Re: patch to fix constant math -5th patch, rtl***From:*Richard Biener

**Re: patch to fix constant math -5th patch, rtl***From:*Richard Sandiford

**Re: patch to fix constant math -5th patch, rtl***From:*Richard Biener

**Re: patch to fix constant math -5th patch, rtl***From:*Richard Sandiford

**Re: patch to fix constant math -5th patch, rtl***From:*Richard Biener

**Re: patch to fix constant math -5th patch, rtl***From:*Richard Sandiford

**Re: patch to fix constant math -5th patch, rtl***From:*Richard Biener

**Re: patch to fix constant math -5th patch, rtl***From:*Richard Sandiford

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

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