From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7CB57385559F; Fri, 17 Mar 2023 17:34:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7CB57385559F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1679074449; bh=EyTXVnwfdxcvE+zMtHk9gyaubWpDcOVtyCJrdQ0rIrs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WpXgdu50QI7wvh+E18N0eoOJlpsZHNhOdytSDYiV7Wl414uTTOAzCthtWPEXTONKn lrVfmRpV2RRFRZheJXQXKBCYT5pHurhtwnh1AA7m6RcxntLyLLlTFTYBoK4ygUJ9Dx QkRdzedJk6vmyxcYSDJswt2eIjVkbbvEGogxirP8= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/108419] [13 Regression] Dead Code Elimination Regression at -O2 since r13-440-g98e475a8f58 Date: Fri, 17 Mar 2023 17:34:08 +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: 13.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org 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: 13.0 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108419 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aldyh at gcc dot gnu.org, | |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Slightly cleaned up testcase: static int b =3D 6, c; long d; short h, i, j; signed char k; void foo (void); short baz (int, int, int, int, int, int, int); short qux (unsigned short, int, char, long); short bar (short l, short m) { return l + m; } static signed char corge (void) { unsigned n; for (n =3D -10U; n >=3D 14; n =3D bar (n, 8)) { i =3D qux (b, 0, c, b); j =3D baz (i, b, d < j, 5, 7, 9, 5); k =3D 200 + n; h =3D k % 5; if (!h) foo (); } return n; } int main () { b || corge (); b =3D 1; } The loop iterates twice, with n -10U and -2U, in third iteration 6U fails t= he 6U >=3D 14 condition. In GCC 12 as well as in r13-439 and r13-440 the loop IV is # ivtmp.30_42 =3D PHI and loop condition is ivtmp.30_34 =3D ivtmp.30_42 + 8; if (ivtmp.30_34 !=3D 206) while trunk has 2 IVs: # RANGE [irange] unsigned int [38, 32767][4294934528, +INF] NONZERO 0xfffffffe # n_32 =3D PHI # RANGE [irange] unsigned int [1, +INF] # ivtmp_2 =3D PHI and # RANGE [irange] unsigned short [30, +INF] NONZERO 0xfffe l.0_27 =3D (unsigned short) n_32; # RANGE [irange] unsigned short [0, 7][38, +INF] NONZERO 0xfffe _28 =3D l.0_27 + 8; # RANGE [irange] short int [-INF, 7][38, +INF] NONZERO 0xfffe _29 =3D (short int) _28; # RANGE [irange] unsigned int [0, 7][38, 32767][4294934528, +INF] NONZERO 0xfffffffe n_30 =3D (unsigned int) _29; ivtmp_43 =3D ivtmp_2 - 1; if (ivtmp_43 !=3D 0) The r13-440 regression is in vrp2, previously we were able to determine that because ivtmp.30_42 is [190, 190][198, 198] then (signed char) of that is [-66, -66][-58, -58] and that % 5 is [-3, -3]= [-1, -1]. Folding statement: _24 =3D (signed char) ivtmp.30_42; - Loops range found for ivtmp.30_42: unsigned char [190, 198] and calcula= ted range :unsigned char [190, 190][198, 205] -Global Exported: _24 =3D signed char [-66, -58] ... irange was : signed c= har [-66, -66][-58, -58] +Global Exported: _24 =3D signed char [-66, -58] Not folded Folding statement: k =3D _24; Not folded Folding statement: _25 =3D _24 % 5; -Global Exported: _25 =3D signed char [-3, -1] ... irange was : signed cha= r [-3, -3][-1, -1] +Global Exported: _25 =3D signed char [-4, 0] is the first difference in the vrp2 dump between r13-439 and r13-440. The other major change is starting with r13-3486-g4c5b1160776382772 when iv= opts uses the 2 IVs rather than one and the convoluted increment by 8. It is actually only a normal increment = by 8 if n_32 is in [0, 32759][-32777U, -1U] but that is actually the case here. I think the ranger doesn't iterate, right? So is there any way that it wou= ld figure out the exact range for the IV?=