From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 7F2B73857C6A; Thu, 18 Nov 2021 09:13:09 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7F2B73857C6A
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/103168] Value numbering for PRE of pure
 functions can be improved
Date: Thu, 18 Nov 2021 09:13:09 +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: 12.0
X-Bugzilla-Keywords: missed-optimization
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: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-103168-4-S9AU4eVidM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-103168-4@http.gcc.gnu.org/bugzilla/>
References: <bug-103168-4@http.gcc.gnu.org/bugzilla/>
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 <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Nov 2021 09:13:09 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103168

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #3)
> This is simple (and fairly common) case we don't optimize
> struct a {
>         int a;
>         static __attribute__ ((noinline))
>         int ret (int v) {return v;}
>=20
>         __attribute__ ((noinline))
>         int inca () {return a++;}
> };
> int
> test()
> {
>         struct a av;
>         av.a=3D1;
>         int val =3D av.ret (0) + av.inca();
>         av.a=3D2;
>         return val + av.ret(0) + av.inca();
> }
>=20
> what ret is const however becaue it is in COMDAT group we only detect it =
as
> pure which makes GVN to give up on proving that its value did not change
> over av.a=3D2 store.  We could easily work this out from modref summary (=
which
> says that function makes no memory load)

This case is a bit different since it just exposes we do not perform any
sort of alias walking for calls in VN.  In fact even with modref we'd need
to perform multiple walks with all stored "pieces" ao_refs.  At least that
should be doable though.

If you can provide a cut&paste place to walk & create those ao_refs I could
see to cook up the relevant VN bits.  But for next stage1 of course.=