On Thu, Apr 25, 2013 at 1:18 AM, Kenneth Zadeck <zad...@naturalbridge.com> wrote: > On 04/24/2013 11:13 AM, Richard Biener wrote: >> >> 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. > > I have tried very hard to make wide-int work very efficiently with both tree > and rtl without biasing the rep towards either representation. Both rtl and > trees constants have a precision. In tree, constants are done better than > in rtl because the tree really does have a field that is filled in that > points to a type. However, that does not mean that rtl constants do not have > a precision: currently you have to look around at the context to find the > mode of a constant that is in your hand, but it is in fact always there. > At the rtl level, you can see the entire patch - we always find an > appropriate mode.
Appearantly you cannot. See Richard S. examples. As of "better", the tree has the issue that we have so many unshared constants because they only differ in type but not in their representation. That's the nice part of RTL constants all having VOIDmode ... Richard.
