Values of WIDE_INT_MAX_ELTS in gcc11 and gcc12 are different

Richard Biener richard.guenther@gmail.com
Fri Nov 5 10:01:14 GMT 2021


On Fri, Nov 5, 2021 at 7:54 AM Jakub Jelinek via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> On Thu, Nov 04, 2021 at 11:05:35PM -0700, Andrew Pinski via Gcc-patches wrote:
> > > I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in GCC11 and GCC12 (on the same X86 machine)
> > >
> > > For gcc11:
> > >
> > > wide int max elts =3
> > >
> > > For gcc12:
> > >
> > > wide int max elts =9
> > >
> > > Does anyone know what’s the reason for this difference?
> > >
> > > Thanks a lot for any help.
> >
> > Yes originally, the x86 backend only used OI and XI modes for vectors
> > during data movement.
> > This changed with r10-5741-gc57b4c22089 which added the use of OI mode
> > for TImode adding with overflow and then MAX_BITSIZE_MODE_ANY_INT
> > changed from 128 to 160 (in r10-6178-gc124b345e46078) to fix the ICE
> > introduced by that change .
> > And then with r12-979-g782e57f2c09 removed the define of
> > MAX_BITSIZE_MODE_ANY_INT.
> > Now what was not mentioned in r12-979-g782e57f2c09 (or before) of why
> > MAX_BITSIZE_MODE_ANY_INT was defined in the first place for x86. HJL
> > assumed there was some problem of why it was defined that way but not
> > realizing memory usage was the reason.
> > It was defined to keep the memory usage down as you see that it is now
> > almost a 3x memory increase for all wi::wide_int.
> > I do think r12-979-g782e57f2c09 should be reverted with an added
> > comment on saying defining MAX_BITSIZE_MODE_ANY_INT here is to
> > decrease the memory footprint.
>
> I completely agree.

Do we have permanent objects embedding wide[st]_int?  I know of
class loop and loop_bound.  Btw, there are other targets with large
integer modes (aarch64 with XImode) and not defining
MAX_BITSIZE_MODE_ANY_INT

Richard.

>         Jakub
>


More information about the Gcc-patches mailing list