From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C45203856257; Tue, 14 Jun 2022 13:10:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C45203856257 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/105838] [10/11/12/13 Regression] g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings Date: Tue, 14 Jun 2022 13:10:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 12.1.0 X-Bugzilla-Keywords: compile-time-hog, memory-hog X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc blocked target_milestone priority cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2022 13:10:17 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105838 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|g++ 12.1.0 runs out of |[10/11/12/13 Regression] |memory or time when |g++ 12.1.0 runs out of |building const std::vector |memory or time when |of std::strings |building const std::vector | |of std::strings Blocks| |93199 Target Milestone|--- |10.4 Priority|P3 |P2 CC| |ebotcazou at gcc dot gnu.o= rg, | |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- Memory usage is from cleanup_empty_eh_merge_phis which deals with a very la= rge number of incoming edges, recording the edge/var mappings. This likely runs into /* The post-order traversal may lead to quadraticness in the redirection of incoming EH edges from inner LPs, so first try to walk the region tree from inner to outer LPs in order to eliminate these edges. */ where we end up re-directing more and more edges again and again. Still the peak memory use is odd, but it might be simply GC garbage piling up in the CFG manipulation odyssee. It's removal of MNT regions - with just 3 elements we go in ehcleanup1 from Before removal of unreachable regions: Eh tree: 25 must_not_throw 1 cleanup land:{12,} 24 cleanup 23 must_not_throw 2 cleanup land:{11,} 22 must_not_throw 3 cleanup land:{10,} 21 must_not_throw 4 cleanup land:{9,} 20 must_not_throw 5 cleanup land:{1,} 19 must_not_throw 6 cleanup land:{8,} 18 must_not_throw 7 cleanup land:{2,} 17 must_not_throw 8 cleanup land:{7,} 16 must_not_throw 9 cleanup land:{3,} 15 must_not_throw 10 cleanup land:{6,} 14 must_not_throw 11 cleanup land:{5,} 13 must_not_throw 12 cleanup land:{4,} to After removal of unreachable regions: Eh tree: 1 cleanup land:{12,} 2 cleanup land:{11,} 3 cleanup land:{10,} 4 cleanup land:{9,} 5 cleanup land:{1,} 6 cleanup land:{8,} 7 cleanup land:{2,} 8 cleanup land:{7,} 9 cleanup land:{3,} 10 cleanup land:{6,} 11 cleanup land:{5,} 12 cleanup land:{4,} but we do this in a sub-optimal order. Axing the first walk: for (i =3D vec_safe_length (cfun->eh->lp_array) - 1; i >=3D 1; --i) { lp =3D (*cfun->eh->lp_array)[i]; if (lp) changed |=3D cleanup_empty_eh (lp); } fixes this but it will go against the PR93199 fix in r10-5868-g5eaf0c498f71= 8f, which the followup r11-3234-gaab6194d0898f5 preserved. I fear the optimal order is different for the clobber optimizations and the edge redirection overhead. In any case a fix should be evaluated against the PR93199 testcase as well. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D93199 [Bug 93199] [9 Regression] Compile time hog in sink_clobbers=