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 >
