13.2.0: backport split match.pd changesHEADmaster

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927#c21.

This should improve (reduce) the peak RAM usage when building GCC as it builds
gimple-match in smaller chunks (previously was one huge generated file) as well
as speeding up parallel build when used.

i.e. This has benefits for both people building on constrained hardware (because
-j1 is more effective and just means each smaller chunk is built one-at-a-time,
not the massive blob) and also for people building with many jobs, as there's
one less synchronisation point so the build is less serial.

Motivated in particular by the upstream report (PR109927) of this being an issue
on m68k with RAM usage for the single GCC process building gimple-match.

(IIRC immolo and possibly dilfridge had mentioned similar issues when building
some arches in qemu as well.)

Note that upstream are planning on splitting insn-* as well so there are further
improvements in the pipeline (see PR54179, but discussion has occurred far more
recently on IRC about this and tamar is likely to look at it.).

Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 (old bug for splitting insn-*, will be revisited)
Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 (tracker bug for parallelisation, interesting discussion)
Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
Bug: https://bugs.gentoo.org/891909 (not the same issue per-se but related to reduced resource usage)
Bug: https://bugs.gentoo.org/894256
Bug: https://bugs.gentoo.org/901317
Signed-off-by: Sam James <sam@gentoo.org>

0 files changed, 0 insertions, 0 deletions