[wide-int] int_traits <tree>

[Kenneth Zadeck]

On 10/16/2013 02:45 PM, Richard Sandiford wrote:
> Kenneth Zadeck <zadeck@naturalbridge.com> writes:
>>> I note that we immediately return in the above case, so
>>>
>>>         if (precision < xprecision + HOST_BITS_PER_WIDE_INT)
>>>           {
>>>             len = wi::force_to_size (scratch, val, len, xprecision,
>>> precision, UNSIGNED);
>>>             return wi::storage_ref (scratch, len, precision);
>>>           }
>>>
>>> applies only when the desired precision is a multiple of a HWI.
>> yes
>>> I assume it adds that extra zero word in case the MSB is set,
>>> right?
>> yes
>>> I am confused about the condition written here and
>>> how we look at precision and not xprecision when deciding how
>>> to extend - given a 8-bit precision unsigned 0xff and precision == 64
>>> we do not even consider sign-extending the value because we look
>>> at precision and not xprecision.  Don't we need to look at
>>> xprecision here?
>> I do not think so.   There are three cases here:
>>
>> 1) xprecision < precision:
>> say xprecision = 8 and precision = 32.
>>
>> The number is between 0 and 255 and after canonicalization the number
>> will be between 0 and 255.
>>
>> 2) xprecision == precision
>> not much to talk about here.
>>
>> 3) xprecision > precision
>>
>> We need to loose the upper bits of the input and it does not matter what
>> they were.    The only thing that we are concerned about is that the
>> bits above what is now the sign bit pointed to by precision are matched
>> in the bits above precision.
> (3) is gone with the assert though.
you seem to be correct here.
> As mentioned in my message yesterday, I thought your new way of canonising
> unsigned tree constants meant that there was always an upper zero bit.
> Is that right?
i believe this is correct.
> If so, xprecision < precision is a no-op, because the number always
> has the right form for wider precisions.  The only difficult case is
> xprecision == precision, since then we need to peel off any upper -1 HWIs.
say my HWI size is 8 bits (just to keep from typing a million 'f's.   if 
i have a 16 bit unsigned number that is all 1s in the tree world it is 3 
hwis
0x00 0xff 0xff.

but inside regular wide int, it would take 1 wide int whose value is 0xff.
inside of max it would be the same as the tree, but then the test 
precision < xprecision + hbpwi never kicks in because precision is 
guaranteed to be huge.

inside of addr_wide_int, i think we tank with the assertion.

the case actually comes up on the ppc because they do a lot of 128 bit 
math.    I think i got thru the x86-64 without noticing this.



> If that's right and xprecision == precision can use val with an adjusted len,
> then...
>
>>> After all an assert precision == xprecision
>>> does not work in this routine.
>>>
>>> Quickly execute.exp tested only.
>>>
>>> To avoid code quality wreckage we have to implement a different way
>>> of allocating the 'scratch' storage of wide_int_ref_storage
>>> (well, ideally we wouldn't need it ...).  I thought of simply
>>> allocating it via alloca (), but we need to do that in all
>>> callers that build a wide_int_ref (eventually via a hidden
>>> default arg).  But as that's a template specialization of
>>> generic_wide_int ... so the option is to provide a function
>>> wrapper inside wi:: for this, like
>> I want richard and mike to be the people who respond to the next
>> point.    I am not a c++ person and all of this storage manager layer
>> stuff gives me a headache.
> ...the use of the scratch array goes away completely for addr_wide_int
> and max_wide_int.  If this code is on a hot path for wide_int then maybe
> we should simply require that wide_int operations involving trees have
> explicit extensions, like in rtl.  (I.e. only do the implicit extension
> for addr_wide_int and max_wide_int.)
i do not understand how this is true.
> I'm not opposed to going back to a separate scratch array if all else fails,
> but it's really ugly, so I'd like to look at the alternatives first...
>
> Thanks,
> Richard