From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C30C73891C2C; Wed, 19 May 2021 07:15:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C30C73891C2C From: "amker at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options Date: Wed, 19 May 2021 07:15:19 +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: amker at gcc dot gnu.org 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: 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: Wed, 19 May 2021 07:15:19 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D100499 --- Comment #19 from bin cheng --- (In reply to bin cheng from comment #18) > Did some experiments, there are two fallouts after explicitly returning > false for unsigned/wrapping types in MULT_EXPR/MINUS_EXPR/PLUS_EXPR. One= is > the mentioned use of multiple_of_p in number_of_iterations_ne, the other = is > for alignment warning in stor-layout.c. As pointed out, the latter case = is > known not overflow/wrap.=20=20 >=20 > So I am thinking to introduce an additional parameter indicating that cal= ler > knows "top" doesn't overfow/wrap, otherwise, try to get rid of the > undocumented assumption. we can always improve the accuracy using ranger= or > other tools. Not sure if this is the right way to do. >=20 > As for MULT_NO_OVERFLOW/PLUS_NO_OVERFLOW, IMHO, it's not that simple? For > example, unsigned_num(multiple of 4, and larger than 0) + 0xfffffffc is > multiple of 4, but it's overflow behavior on which we rely here. Hmm, 4 is special and not a correct example. Considering: n (unsigned, multiple of 3, and > 0) + 0xfffffffd It's multiple of 3, but we need to rely on wrapping to get answer.=