On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford <rdsandif...@googlemail.com> wrote: > Richard Biener <richard.guent...@gmail.com> writes: >> On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford >> <rdsandif...@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
