From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 7F8233854804 for ; Tue, 16 Mar 2021 15:02:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7F8233854804 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Thomas_Schwinge@mentor.com IronPort-SDR: kCvnN2dqWo9L7+acSmkmEpGTwV+cMT1/3KDOoLtoyBt+yrPRnnV1ScR0Wd56BmQcdKJyH9EeY4 hRgvj+BX5jXX3WDpN+hVLQ2pEvBYuz5trLecMqS4oIw+mqcEIkHRr7t266ofSyNyx39cKiaDt9 tVnn2O6f7pyPR0S9MaGRIK0pzGEEun3kunmBq5xv24yU9OfX+QzIWOB9lxA0xaaJhfreqx1VIL OLKLQU/6jdVKqboOAaZVZ8yJGkfB2N/la390Qz5bk7p91BhTPhHK0LeIiBMl+7UNNugkBwjhuh ClU= X-IronPort-AV: E=Sophos;i="5.81,251,1610438400"; d="scan'208";a="59279042" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 16 Mar 2021 07:02:54 -0800 IronPort-SDR: N+xF7mgDBQXXegH6g2qNnHmzGRCTSC1Pji6oukoJAq6lxd102nrKqQUG+YPK7KFHU8+Wxth/Ea 1pRvQin/2sqoyjgaGunfLgd/WUKzxkEHp5JERqq4CvwDddlQFP1BwSvrktjN+2JYYYtaqLPiag YM7W4FKN6IqkGS1lGPjx1K5+Bc3ZYJ0jkjmsmTScHnVJU0+gjaXi/r1CHZVyFAMAmfLLV65RFu 01F0OngHS66AG9xQMdX/I8eI68gvHzsiACmF54Y1Bi4scyEQeVj9QGzVuz7hlbyFcTzd2xLH5y wd4= From: Thomas Schwinge To: Richard Biener , Subject: Re: 'walk_stmt_load_store_addr_ops' for non-'gimple_assign_single_p (stmt)' In-Reply-To: References: <87pn00z2st.fsf@euler.schwinge.homeip.net> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Tue, 16 Mar 2021 16:02:42 +0100 Message-ID: <87mtv3ywdp.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-05.mgc.mentorg.com (139.181.222.5) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 15:02:57 -0000 Hi! Richard, thanks for your answer. I'll need to look into this more; two questions already: On 2021-03-15T20:17:17+0100, Richard Biener via Gcc wrote= : > On March 15, 2021 7:31:46 PM GMT+01:00, Thomas Schwinge wrote: >>First time I'm using this API -- so the error certainly may be on my >>side. ;-) >> >>What I'm doing, is a 'walk_gimple_seq', and in that one's >>'callback_stmt', call 'walk_stmt_load_store_addr_ops', to collect >>variable load/store/address-taken instances. This did seem quite >>straight-forward, given the description; 'gcc/gimple-walk.c': >> >>/* For the statement STMT call the callbacks VISIT_LOAD, VISIT_STORE >>and >> VISIT_ADDR if non-NULL on loads, store and address-taken operands >>passing the STMT, the base of the operand, the operand itself >>containing >> the base and DATA to it. The base will be either a decl, an indirect >> reference (including TARGET_MEM_REF) or the argument of an address >> expression. >> Returns the results of these callbacks or'ed. */ >> >> bool >> walk_stmt_load_store_addr_ops (gimple *stmt, void *data, >> walk_stmt_load_store_addr_fn visit_load, >> walk_stmt_load_store_addr_fn visit_store, >> walk_stmt_load_store_addr_fn visit_addr) >> { [...] } >> >>Indeed, given (Fortran) 'zzz =3D 1', we produce GIMPLE: >> >> gimple_assign >> >>..., and calling 'walk_stmt_load_store_addr_ops' on that, I see, as >>expected, the 'visit_store' callback invoked, with 'rhs' and 'arg': >>''. >> >>However, given (Fortran) 'zzz =3D r + r2', we produce GIMPLE: >> >> gimple_assign >> >>..., and calling 'walk_stmt_load_store_addr_ops' on that, I see, >>unexpectedly, no callback at all invoked: neither 'visit_load', nor >>'visit_store' (nor 'visit_address', obviously). > > The variables involved are registers. You only get called on memory opera= nds. How would I have told that from the 'walk_stmt_load_store_addr_ops' function description? (How to improve that one "to reflect relatity"?) But 'zzz' surely is the same in 'zzz =3D 1' vs. 'zzz =3D r + r2' -- for the former I *do* see the 'visit_store' callback invoked, for the latter I don't? >>From a quick look at 'gcc/gimple-walk.c:walk_stmt_load_store_addr_ops', >>this seems to intentionally be implemented in this way -- but I don't >>understand the rationale? >> >> >>Instead of 'walk_gimple_seq' -> 'callback_stmt' -> >>'walk_stmt_load_store_addr_ops', do I need to use 'walk_gimple_seq' -> >>'callback_op' -> "something"? > > Yes, if you want to visit register sets and uses as a well. Note you'll a= lso see constants that way. I'll look into that; in particular to figure out "something" for what I need: load/store/address-taken. Gr=C3=BC=C3=9Fe Thomas ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 M=C3=BCnchen R= egistergericht M=C3=BCnchen HRB 106955, Gesch=C3=A4ftsf=C3=BChrer: Thomas H= eurung, Frank Th=C3=BCrauf