https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2024-01-24
Ever confirmed|0 |1
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ah, I can reproduce - there are allocation spikes with a i586 compiler,
always during DF which oddly enough do not happen with a x86_64 compiler.
The course of action would be to reduce the testcase to a single function
(I've starting from a x86_64->riscv cross tree preprocessed source with -m32
added, so a bit of a "wrong" testcase). Just keeping init_all_optabs
seems to reproduce it.
Reducing the number of stores to ena[] makes it eventually fit - cutting
in half seems to work for me but I still see a 1.5GB peak.
Oddly enough a checking enabled x86_64 hosted compiler shows similar bad
performance.
IIRC DF issues with many adjacent stores are not unheard of. Possibly
on x86_64 store-merging helps to avoid this.
That said, a "fix" could be to adjust the insn-opinit generator to
emit multiple init_all_optabs functions, doing 1000 at a time.
