From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 319963858420; Thu, 18 Nov 2021 09:39:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 319963858420 From: "hubicka at kam dot mff.cuni.cz" 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:39:24 +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: hubicka at kam dot mff.cuni.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 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: Thu, 18 Nov 2021 09:39:25 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103168 --- Comment #5 from hubicka at kam dot mff.cuni.cz --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103168 >=20 > --- Comment #4 from Richard Biener --- > (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 i= t 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) >=20 > 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. Yep, it was my original intention to point out this :) >=20 > If you can provide a cut&paste place to walk & create those ao_refs I cou= ld > see to cook up the relevant VN bits. But for next stage1 of course. The following should work (pretty much same loop is in dse_optimize_call but for stores instead of loads.) bool unknown_memory_access =3D false; if (summary =3D get_modref_function_summary (stmt, NULL)) { /* First search if we can do someting useful. Like for dse it is easy to precompute in the summary now and will be happy to implement that. */ for (auto base_node : summary->loads->bases) if (base_node->all_bases || unknown_memory_access) { unknown_memory_access =3D true; break; } else for (auto ref_node : base_node->refs) if (ref_node->all_refs) { unknown_memory_access =3D true; break; } /* Do the walking. */ if (!unknown_memory_access) for (auto base_node : summary->loads->bases) for (auto ref_node : base_node->refs) if (ref_node->all_refs) unknown_memory_access =3D true; else for (auto access_node : ref_node->accesses) if (access_node.get_ao_ref (stmt, &ref) { ref.base_alias_set =3D base_node->base; ref.ref_alias_set =3D ref_node->base; ... do refwalking } else if (get_call_arg (stmt)) ... we do not know offset but can still walk using ptr_deref_may_alias_ref_p_1 else unknown_memory_access =3D true; ... unlikely to happen (for example when number of args in call stmt mismatches the actual function bod= y) } if (unknown_memory_access) ... even here walking makes sense to skip stores to that passes !ref_maybe_used_by_call_p ... do walk for function arguments passed by value >=20 > --=20 > You are receiving this mail because: > You reported the bug.=