From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2F7F73858D3C; Thu, 16 Dec 2021 03:04:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2F7F73858D3C From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/91789] Value ranges determined from comparisons not used transitively Date: Thu, 16 Dec 2021 03:04:34 +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: 10.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: amacleod at redhat dot com 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: --- 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, 16 Dec 2021 03:04:34 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D91789 --- Comment #7 from Andrew Macleod --- hmm. yeah. we have the knowledge... but how to apply it efficiently. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Imports: a_3(D) Exports: a_3(D) b_2(D) int VARYING a_3(D) int VARYING Relational : (b_2(D) >=3D a_3(D)) : if (a_3(D) < 0) goto ; [INV] else goto ; [INV] 4->5 (T) a_3(D) : int [-INF, -1] 4->6 (F) a_3(D) : int [0, +INF] We know the relationship upon entry to BB 4, but with no reference to b_2, there is no reason to update b_2's range. b_2 may never be reference again. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB 6 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Imports: b_2(D) Exports: b_2(D) b_2(D) int VARYING : if (b_2(D) < 0) goto ; [INV] else goto ; [INV] 6->7 (T) b_2(D) : int [-INF, -1] 6->8 (F) b_2(D) : int [0, +INF] And upon entry to BB6, we do know that a_3 is [0, +INF], but with no refere= nce to a_3 in this block, we don't see any reason to look to see if there is a relationship. And with no further references to a_3 in the IL, we wont propagate its value to here either. THe problem is that unless we do an exhaustive search of every possible relation of b_2, there is nothing in the IL at each point to indicate we sh= ould look at the other name. Perhaps it isnt as bad as I make it sound. r perhaps I can add relations to the export list for a block and have gori figure it out. IE, in bb4 a_3 is the only export, and we can calculate a range for it.=20 If we note at this point that there is a relation between a_3 and b_2, perh= aps I can add b_2 to the export list as well, and the GORI how to process the relation much like it process recalculations. IF we have c_9 =3D a_3 - 10 somewhere in the program, we note the dependenc= e of c_9 on a_3, and we "recalculate" c_9 as [0,+INF] - 10 =3D=3D [-10, +INF-10= ] on that edge. Perhaps I can likewise add relations to this recomputation and flag b_3 as a recomputation.. Since the relation is technically "true", it could be solved for b_2 as=20 [1, 1] =3D b_2(D) >=3D [1, +INF] and everything should just work...=20 hmm.=20=20 I shall give it a go after a bit more thought.=