From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D49E6385841E; Wed, 13 Mar 2024 10:47:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D49E6385841E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1710326879; bh=fHn40elRcW54wvnELzg2T9EdCfIbrqMe+2RxN7fKRMI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=U0iCLVSdDC9UBqBsVhjKD8HSqIP/bicrZ7wGomzIlaPms2PLOgVDPh9iyHSngfxhW dh96zDxoXbrfguVPeha0Cw2/P61GPTJ6bHpg7LGA9XxayxGk+Oh64ru0zcOBQFrhRl qIzKZS55gKNxqVRIfAnQuWx/ZfzyRDrdPJpOx2oA= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/114322] [14 Regression] SCEV analysis failed for bases like A[(i+x)*stride] since r14-9193-ga0b1798042d033 Date: Wed, 13 Mar 2024 10:47:59 +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: 14.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth 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: 14.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: target_milestone cf_reconfirmed_on bug_status everconfirmed 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=3D114322 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |14.0 Last reconfirmed| |2024-03-13 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. The issue is we have { x_12(D), +, 1 } * stride_11(D) which doesn't behave the same with respect to overflow as { x_12(D) * stride_11(D), +, stride_11(D) } and because of that we analyze it as (int) {(unsigned) x_12(D) * (unsigned) stride_11(D), +, (unsigned) stride_11(D) } as it might wrap. But then then sign-extension to long unsigned int is no longer affine. _1 =3D x_12(D) + i_20; _2 =3D _1 * stride_11(D); _3 =3D (long unsigned int) _2; _4 =3D _3 * 2; _5 =3D A_13(D) + _4; _6 =3D *_5; The problematical case is x =3D=3D N < 0 where the last - N might now overflow with the new SCEV. The correctness means that we'll now more often run into these issues for IVs smaller than pointer width. With -m32 we can analyze the DR to Creating dr for *_5 offset from base address: 0 constant offset from base address: 0 step: (ssizetype) ((unsigned int) stride_11(D) * 2) base alignment: 2 base misalignment: 0 offset alignment: 256 step alignment: 2 base_object: *A_13(D) + (sizetype) ((unsigned int) stride_11(D) * (unsigned int) x_12(D)) * 2 Access function 0: {0B, +, (unsigned int) stride_11(D) * 2}_1 If you had written sum +=3D A[i*stride + x*stride]; it might have worked but unfortunately EVRP transforms this back to (i+x)*stride because it knows stride isn't zero. In the end this means it's our failure that we fail to handle 2 * (unsigned long)({ x_12(D), +, 1 } * stride_11(D)) as valid evolution for further analysis - of course the multiplication by two in an unsigned type might overflow as well.=