From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 120F83858C20; Mon, 31 Jan 2022 10:52:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 120F83858C20 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/103006] [9/10/11/12 Regression] wrong code at -O1 or -O2 on x86_64-linux-gnu by r7-7101 Date: Mon, 31 Jan 2022 10:52:46 +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: 12.0 X-Bugzilla-Keywords: wrong-code 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: 9.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Mon, 31 Jan 2022 10:52:47 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103006 --- Comment #11 from Richard Biener --- (In reply to rguenther@suse.de from comment #8) > On Tue, 2 Nov 2021, jakub at gcc dot gnu.org wrote: >=20 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103006 > >=20 > > --- Comment #7 from Jakub Jelinek --- > > Looks like that. > > What do you think about unrolling making variable copies? We'd need to= be sure > > that the scope of the variable is the loop we are unrolling though (or > > something nested in it). >=20 > Being able to determine that would solve the very issue we're trying > to fix with making the copy. The problem is that we put in CLOBBERs > based on the original BINDs but later optimizers do not respect the > birth boundary. If we can figure that out we could ignore the > respective CLOBBERs for the CFG expansion live compute as well. >=20 > I think we may be able to compute the CFG SCC a CLOBBER resides in > and in case the CLOBBERed variable is live-in into that SCC we cannot > prune it with that CLOBBER. Or so. Tried that but while it solves PR97821 it doesn't fix the case in this bug because there the CLOBBER that breaks things is not inside a SCC but the issue in this case is that not all accesses to 'h' also mention h and thus we miss to make 'h' live again after the CLOBBER. I also fear the more variables we expose the easier it will be to run into this issue. It might be possible to (conservatively) track pointers from ADDR_EXPR mentions, but that's going to give up in most of the interesting cases (it has the same issue as ideas how to prevent "leakage" via pointers). The other idea that we discussed past in time is to perform stack slot shar= ing early when the CLOBBERs are still OK to use. Possibly even w/o CLOBBERs but with the GIMPLE binds we have even after gimplifying. We'd make the "stack slot" sharing explicit by replacing decls assigned to the same stack slot with either the larges of the decls or anonymous stack memory (a new decl). Doing this before inlining is complete will obviously not catch all important cases. Doing it after inlining requires being careful during early optimizations (jump threading is the one transform we do early that can cause code duplication and followup CSE).=