Richard Biener <rguent...@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
