On Thu, Jan 23, 2020 at 10:33 AM Jakub Jelinek <ja...@redhat.com> wrote: > > On Thu, Jan 23, 2020 at 09:14:42AM +0000, Richard Sandiford wrote: > > > The other patch is something suggested by Richard S., avoid using OImode > > > for this and instead use a partial int mode that is smaller. This is > > > still > > > playing with fire because even the partial int mode is larger than > > > MAX_BITSIZE_MODE_ANY_INT, but at least its precision fits into those 3 > > > WIDE_INT_MAX_ELTS wide-int.h uses. > > > > I think we should increase MAX_BITSIZE_MODE_ANY_INT to the precision > > of POImode at the same time, and make that precision less than 192 > > (191 maybe?). That way everything is "correct" without increasing > > the size of wide_int. > > The 192 was chosen just to be nice and round, I guess it could be just 130 > or say 160 (128 + 32). > > Uros, would you be ok with bumping MAX_BITSIZE_MODE_ANY_INT to 160 > and changing the POImode patch to use 160 bits instead of 192 > if it passes testing?
We can try 160 and hope that nothing breaks due to "weird" number. Uros. > I guess it would still affect the sizes of the wide-int.cc arrays: > unsigned HOST_HALF_WIDE_INT > u[4 * MAX_BITSIZE_MODE_ANY_INT / HOST_BITS_PER_HALF_WIDE_INT]; > unsigned HOST_HALF_WIDE_INT > v[4 * MAX_BITSIZE_MODE_ANY_INT / HOST_BITS_PER_HALF_WIDE_INT]; > /* The '2' in 'R' is because we are internally doing a full > multiply. */ > unsigned HOST_HALF_WIDE_INT > r[2 * 4 * MAX_BITSIZE_MODE_ANY_INT / HOST_BITS_PER_HALF_WIDE_INT]; > so if we didn't want that, we would need to use 132; but those > are weird anyway, because they round down rather than up. > > Jakub >
