On Fri, May 3, 2013 at 1:49 PM, Kenneth Zadeck <zad...@naturalbridge.com> wrote: > On 05/03/2013 07:34 AM, Richard Biener wrote: >> >> 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. > > I said we could always find a mode, i did not say that in order to find the > mode we did not have to stand on our head, juggle chainsaws and say "mother > may i". The decision to leave the mode as void in rtl integer constants > was made to save space, but comes with an otherwise very high cost and in > today's world of cheap memory seems fairly dated. It is a decision that i > and others would love to change and the truth is wide int is one step in > that direction (in that it gets rid of the pun of using double-int for both > integers and floats where the discriminator is voidmode for ints.) But for > now we have to live with that poor decision.
As far as I have read your wide-int patches the CONST_WIDE_INT RTX object does not include a mode. So I don't see it as a step forward in any way (other than that it makes it explicit that you _do_ need a mode to do any operation on a constant). Richard.