On 10/31/2012 09:54 AM, Richard Biener wrote:
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.
it is now 4x not 2x to accomodate the extra bit in tree-vrp.
remember that the space burden is minimal. wide-ints are not
persistent and there are never more than a handful at a time.
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 ;)
yes, but tree-vrp does not even work for timode. and there are not
tests to scale it back when it does see ti-mode. I understand that
these can be added, but they so far have not been.
I would also point out that i was corrected on this point by (i believe)
lawrence. He points out that tree-vrp is still important for
converting signed to unsigned for larger modes.
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
