From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 05FA83959E5D; Wed, 27 Jan 2021 14:35:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 05FA83959E5D From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/80960] [8/9/10/11 Regression] Huge memory use when compiling a very large test case Date: Wed, 27 Jan 2021 14:35:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 6.3.0 X-Bugzilla-Keywords: memory-hog X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status assigned_to 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: Wed, 27 Jan 2021 14:35:35 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D80960 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot = gnu.org --- Comment #25 from Richard Biener --- Oh, so it's not actually that plus_constant calls but the ones called via get_addr from true_dependence_1 which is called 60 million times from check_mem_read_use. That does: /* Convert the address X into something we can use. This is done by return= ing it unchanged unless it is a VALUE or VALUE +/- constant; for VALUE we call cselib to get a more useful rtx. */ rtx get_addr (rtx x) { cselib_val *v; struct elt_loc_list *l; if (GET_CODE (x) !=3D VALUE) { if ((GET_CODE (x) =3D=3D PLUS || GET_CODE (x) =3D=3D MINUS) && GET_CODE (XEXP (x, 0)) =3D=3D VALUE && CONST_SCALAR_INT_P (XEXP (x, 1))) { rtx op0 =3D get_addr (XEXP (x, 0)); if (op0 !=3D XEXP (x, 0)) { poly_int64 c; if (GET_CODE (x) =3D=3D PLUS && poly_int_rtx_p (XEXP (x, 1), &c)) return plus_constant (GET_MODE (x), op0, c); thus undoing the valueization DSE does. Since it unconditionally does this I guess DSE could do it itself instead. That helps tremendously: dead store elim2 : 6.34 ( 11%) 0.02 ( 7%) 6.38 ( = 11%) 170M ( 45%) TOTAL : 56.96 0.27 57.26=20= =20=20=20=20=20=20 381M 56.96user 0.29system 0:57.27elapsed 99%CPU (0avgtext+0avgdata 825148maxresident)k 0inputs+0outputs (0major+210372minor)pagefaults 0swaps diff --git a/gcc/dse.c b/gcc/dse.c index c88587e7d94..da0df54a2dd 100644 --- a/gcc/dse.c +++ b/gcc/dse.c @@ -2219,6 +2219,11 @@ check_mem_read_rtx (rtx *loc, bb_info_t bb_info) } if (maybe_ne (offset, 0)) mem_addr =3D plus_constant (get_address_mode (mem), mem_addr, offset); + /* Avoid passing VALUE RTXen as mem_addr to canon_true_dependence + which will over and over re-create proper RTL and re-apply the + offset above. See PR80960 where we almost allocate 1.6GB of PLUS + RTXen that way. */ + mem_addr =3D get_addr (mem_addr); if (group_id >=3D 0) {=