On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford <rdsandif...@googlemail.com> wrote: > Richard Biener <richard.guent...@gmail.com> writes: >> I suppose the above should use immed_double_int_const (v, mode), too, > > In practice it doesn't matter, because... > >> which oddly only ever truncates to mode for modes <= HOST_BITS_PER_WIDE_INT >> via gen_int_mode. > > ...right. That's because there's not really any proper support for > non-power-of-2 modes. Partial modes like PDI are specified by things like: > > PARTIAL_INT_MODE (DI); > > which is glaringly absent of any bit width. So if the constant is big > enough to need 2 HWIs, it in practice must be exactly 2 HWIs wide.
Ah, of course. > One of the advantages of wide_int is that it allows us to relax this > restriction: we can have both (a) mode widths greater than > HOST_BITS_PER_WIDE_INT*2 and (b) mode widths that are greater than > HOST_BITS_PER_WIDE_INT while not being a multiple of it. > > 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). Richard. > Richard
