From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B31E93858D39; Fri, 24 Nov 2023 21:52:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B31E93858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1700862759; bh=jihGvIIlCYghqR2pv4vir0s6hWH3pwpQqco/DcuGJ6o=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cRMCk04lLrMbclGIvac6BbvxEu8FzzqgE2Web/4LodE/NXYLiRk3q1zPs2RmhRjLO rMD+FHaQKyPHhcOgN7dvIvR5lsiFSnf36yc9LvBjc1k5iWW7XFEZnuGs8DBvehAk0V sSkC+IB1v3IE8nkDctIbHJzSa4KEHnWsQ2kwgrTg= From: "hubicka at ucw dot cz" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/112706] missed simplification in FRE Date: Fri, 24 Nov 2023 21:52:39 +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: unknown X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: hubicka at ucw dot cz 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112706 --- Comment #3 from Jan Hubicka --- Thanks, new pattern looks like noticeable improvement :) Base+offset is effective for alias analysis and I suppose it happens reasonably enough for compares as well. > _76 =3D _71 + 4; > # .MEM_154 =3D VDEF <.MEM_153> > x_3(D)->D.25942._M_implD.25172.D.25249._M_finishD.25175 =3D _76; > # .MEM_7 =3D VDEF <.MEM_154> > D.26033 =3D 0; > # .MEM_157 =3D VDEF <.MEM_7> > *_76 =3D 0; > # PT =3D nonlocal escaped=20 > _82 =3D _71 + 8; > # .MEM_158 =3D VDEF <.MEM_157> > x_3(D)->D.25942._M_implD.25172.D.25249._M_finishD.25175 =3D _82; > # .MEM_8 =3D VDEF <.MEM_158> > D.26033 =3D{v} {CLOBBER(eol)}; > # .MEM_9 =3D VDEF <.MEM_8> > D.26034 =3D 0; > if (_66 !=3D _82) > ``` > After pre (note the first comparison is gone but not the second one and m= aybe a > 3rd). So this patch helps but it looks like a PRE/VN improvement is still > needed to fix the others. I think it is missing predication in VN. At each execution of CCP or VN we work out one conditional to be true, but we stil account both paths for the value number of the pointer used in next compare. If vector used base+size pair instead of base+endptr VRP would help here, but we can't vrp finish-start range...=