On Wed, Oct 31, 2012 at 2:30 PM, Richard Sandiford <rdsandif...@googlemail.com> wrote: > Richard Biener <richard.guent...@gmail.com> writes: >>> But that means that wide_int has to model a P-bit operation as a >>> "normal" len*HOST_WIDE_INT operation and then fix up the result >>> after the fact, which seems unnecessarily convoluted. >> >> It does that right now. The operations are carried out in a loop >> over len HOST_WIDE_INT parts, the last HWI is then special-treated >> to account for precision/size. (yes, 'len' is also used as optimization - >> the >> fact that len ends up being mutable is another thing I dislike about >> wide-int. If wide-ints are cheap then all ops should be non-mutating >> (at least to 'len')). > > But the point of having a mutating len is that things like zero and -1 > are common even for OImode values. So if you're doing someting potentially > expensive like OImode multiplication, why do it to the number of > HOST_WIDE_INTs needed for an OImode value when the value we're > processing has only one significant HOST_WIDE_INT?
I don't propose doing that. I propose that no wide-int member function may _change_ it's len (to something larger). Only that way you can avoid allocating wasted space for zero and -1. That way also the artificial limit on 2 * largest-int-mode-hwis goes. >>> I still don't >>> see why a full-precision 2*HOST_WIDE_INT operation (or a full-precision >>> X*HOST_WIDE_INT operation for any X) has any special meaning. >> >> Well, the same reason as a HOST_WIDE_INT variable has a meaning. >> We use it to constrain what we (efficiently) want to work on. For example >> CCP might iterate up to 2 * HOST_BITS_PER_WIDE_INT times when >> doing bit-constant-propagation in loops (for TImode integers on a x86_64 >> host). > > But what about targets with modes wider than TImode? Would double_int > still be appropriate then? If not, why does CCP have to use a templated > type with a fixed number of HWIs (and all arithmetic done to a fixed > number of HWIs) rather than one that can adapt to the runtime values, > like wide_int can? Because nobody cares about accurate bit-tracking for modes larger than TImode. And because no convenient abstraction was available ;) >> Oh, and I don't necessary see a use of double_int in its current form >> but for an integer representation on the host that is efficient to manipulate >> integer constants of a target dependent size. For example the target >> detail that we have partial integer modes with bitsize > precision and that >> the bits > precision appearantly have a meaning when looking at the >> bit-representation of a constant should not be part of the base class >> of wide-int (I doubt it belongs to wide-int at all, but I guess you know more >> about the reason we track bitsize in addition to precision - I think it's >> abstraction at the wrong level, the tree level does fine without knowing >> about bitsize). > > TBH I'm uneasy about the bitsize thing too. I think bitsize is only > tracked for shift truncation, and if so, I agree it makes sense > to do that separately. So, can we please remove all traces of bitsize from wide-int then? > But anyway, this whole discussion seems to have reached a stalemate. > Or I suppose a de-facto rejection, since you're the only person in > a position to approve the thing :-) There are many (silent) people that are able to approve the thing. But the point is I have too many issues with the current patch that I'm unable to point at a specific thing I want Kenny to change after which the patch would be fine. So I rely on some guesswork from Kenny giving my advices "leaner API", "less fused ops", "get rid of bitsize", "think of abstracting the core HWI[len] operation", "there should be no tree or RTL dependencies in the wide-int API" to produce an updated variant. Which of course takes time, which of course crosses my vacation, which in the end means it isn't going to make 4.8 (I _do_ like the idea of not having a dependence on host properties for integer constant representation). Btw, a good hint at what a minimal wide-int API would look like is if you _just_ replace double-int users with it. Then you obviously have to implement only the double-int interface and conversion from/to double-int. Richard. > Richard
