Determine more IVs to be non-overflowing

[Richard Sandiford]

Richard Biener <rguenther@suse.de> writes:
> On Tue, 5 Jul 2016, Jan Hubicka wrote:
>
>> > On Tue, 5 Jul 2016, Richard Biener wrote:
>> > 
>> > >given widest_int has only precision of TImode on x86_64?
>> > 
>> > Is that the case? The comments say:
>> > 
>> >      It is really finite precision math where the precision is 4 times the
>> >      size of the largest integer that the target port can represent.
>> > 
>> > And the target has
>> > 
>> > /* Keep the OI and XI modes from confusing the compiler into thinking
>> >    that these modes could actually be used for computation.  They are
>> >    only holders for vectors during data movement.  */
>> > #define MAX_BITSIZE_MODE_ANY_INT (128)
>> > 
>> > I would thus expect widest_int to have at 512 bits on x86_64
>> > (possibly more depending on the exact definition of largest
>> > integer).
>> 
>> I think that comment is just confusing. (I got trapped by it, too)

FWIW, I think the comment dates from Kenny's original patch, where
widest_int really was suitable as an approximation of "infinite"
precision.  That got changed during review because of space concerns.

>> /* The MAX_BITSIZE_MODE_ANY_INT is automatically generated by a very
>>    early examination of the target's mode file.  The WIDE_INT_MAX_ELTS
>>    can accomodate at least 1 more bit so that unsigned numbers of that
>>    mode can be represented as a signed value.  Note that it is still
>>    possible to create fixed_wide_ints that have precisions greater than
>>    MAX_BITSIZE_MODE_ANY_INT.  This can be useful when representing a
>>    double-width multiplication result, for example.  */
>> 
>> #define WIDE_INT_MAX_ELTS \
>>   ((MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT) / HOST_BITS_PER_WIDE_INT)
>> 
>> #define WIDE_INT_MAX_PRECISION (WIDE_INT_MAX_ELTS * HOST_BITS_PER_WIDE_INT)
>> 
>> typedef FIXED_WIDE_INT (WIDE_INT_MAX_PRECISION) widest_int;
>> 
>> My reading is that the type will end up being 128+64 bits, but there is only
>> one extra bit guarnatee in general, which is taken by sign.
>
> Yeah, I think the other comment should be adjusted accordingly.  I
> didn't remember we have that one extra bit either ... ;)  (given wide-ints
> have unsigned variants of ops I wonder if it is really necessary, but who
> knows - the wide-int rep w/o a sign is really sth odd and I blame RTL 
> for it).

Hmm, yeah.  We definitely need the extra bit for widest_int, but I'm
not sure why we need it for wide_int.

Thanks,
Richard