From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A951A3844072; Tue, 18 May 2021 15:46:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A951A3844072 From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options Date: Tue, 18 May 2021 15:46:50 +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.2.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: P3 X-Bugzilla-Assigned-To: amker at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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, 18 May 2021 15:46:50 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D100499 Andrew Macleod changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msebor at gcc dot gnu.org --- Comment #16 from Andrew Macleod --- Aldy and I are discussing this. Ranger itself can't do anything outside of the gimple IL, its effectively j= ust a GIMPLE interface to range-ops. ... but I don't think it would be hard to= add a range-ops expression evaluator. I notice the multiple_of_p's "top" argum= ent is an expression tree ie: g_2823_lsm.5_13 * 7854 + 57682 We could add an expression evaluator that can walk that expression, invoking range-ops on each expression, and calling a ranger instance to evaluate a r= ange for any ssa_name it finds. It would bail if there are unknown tree-codes to range-ops.=20 I don't think this is a particularly difficult thing to do, but by itself doesn't really tell you if an overflow is possible Once we can evaluate an expression outside of the IL like this, it would al= so not be difficult to then evaluate the expression in an increased precision.= =20=20 We could cast the range at each point of the evaluation to the increased precision and invoke range-ops on that range. We could tell at any point i= f an overflow is possible because the increased precision calculation would be different than the original. so the original expression is in 16 bit math, and if it was evaluated as [0, 65535] * [7854, 7854] + [57682, 57682] in 32 bit precision, it would come back with the answer [57682, 514769572]. Casting the final original value to 32 bit would yield a different result, = and we could conclude than an overflow is possible. Would this be useful? and would it solve this problem? I'm sure there are other details to work out related to the increased precision, but it seems = like it might work?=20=20=20 I think Martin Sebor was also interested in something along these lines so = I'm CC ing him. I think he wanted to do this within the IL for some of his warnings.. but I think something similar is feasible with an IL walk rather than expression walk.=