From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 602E53858422; Tue, 2 Nov 2021 08:10:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 602E53858422 From: "rguenther at suse dot de" 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: Tue, 02 Nov 2021 08:10:57 +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: ra, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 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: Tue, 02 Nov 2021 08:10:57 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103006 --- Comment #8 from rguenther at suse dot de --- On Tue, 2 Nov 2021, jakub at gcc dot gnu.org wrote: > 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 b= e sure > that the scope of the variable is the loop we are unrolling though (or > something nested in it). 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. 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.=