From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 790BB3858D35; Thu, 20 Jan 2022 00:10:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 790BB3858D35 From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/103721] [12 regression] wrong code generated for loop with conditional since r12-4790-g4b3a325f07acebf4 Date: Thu, 20 Jan 2022 00:10:21 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 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: Thu, 20 Jan 2022 00:10:21 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103721 --- Comment #10 from Andrew Macleod --- (In reply to Jeffrey A. Law from comment #9) >=20 >=20 >=20 > 1 2 3 > | \ / > | 4 > | / \ > +->5 6 > / \ > 7 8 >=20 >=20 > Note how BB4 does not dominate BB5. If we try to thread something like > 2->4->5->?, then can't we run into problems with the equivalence handling= as > well, even though we're not dealing with a loop? Well, if the top of the path does not dominate an element of the path.. then maybe yes. The way it currently works, the assumption is that each node of the path dominates the previous node. and for processing the path itself, this shoul= d be fine since we add relations as we walk the path and its a linear path. The problem with back edges was we start to see the same SSA name a second time... which is really bad karma and we really need to reset the path relations immediately. The next problem which you point out is when a relation does not occur in t= he path. Then we query from the top of the path using ranger. So if the top of the path does not dominate some element of the path, and we make a query from there, then yes, we are open to an possible issue if we m= ake a ranger query. Otherwise I think we are OK because we are simply walking = the path and by definition the earlier elements of the path dominate the next o= ne. . Perhaps the rule should be... if the next block is not dominated by the pa= th root, reset all relations, and reset the root to the common dominator of the original root and the new node?=20=20=20 OR perhaps thats too aggressive and we reset path relations only on back ed= ges, and reset the root to the common dominator whenever we encounter a node not dominated by the path start?=