From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id 33B33385840A for ; Thu, 11 Nov 2021 12:42:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 33B33385840A Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 03D152827E7; Thu, 11 Nov 2021 13:42:44 +0100 (CET) Date: Thu, 11 Nov 2021 13:42:43 +0100 From: Jan Hubicka To: Richard Biener Cc: GCC Patches Subject: Re: Use modref summary to DSE calls to non-pure functions Message-ID: <20211111124243.GA17431@kam.mff.cuni.cz> References: <20211110124316.GF97553@kam.mff.cuni.cz> <20211111120715.GC47134@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2021 12:42:46 -0000 Hi, > > No, I think if it turns out useful then we want a way to have such ref > represented by an ao_ref. Note that when we come from a > ref tree we know handled-components only will increase offset, > only the base MEM_REF can contain a pointer subtraction (but > the result of that is the base then). Yep, that is why I introduced the parm_offset at first place - it can be negative or unknown... > > In what cases does parm_offset_known end up false? Is that > when seeing a POINTER_PLUS_EXPR with unknown offset? Yep, a typical example is a loop with pointer walking an array . > So yes, that's a case we cannot capture right now - the only > thing that remains is a pointer with a known points-to-set - a > similar problem as with the pure call PRE. You could in theory > allocate a scratch SSA name and attach points-to-info > to it. And when the call argument is &decl based then you could set > offset to zero. Hmm, I could try to do this, but possibly incrementally? Basically I want to have foo (&decl) decl = {} To be matched since even if I do not know the offset I know it is dead after end of lifetime of the decl. I am not quite sure PTA will give me that? > > It was my initial plan. However I was not sure how much I would get from > > that. > > > > The function starts with: > > > > /* Don't return early on *this_2(D) ={v} {CLOBBER}. */ > > if (gimple_has_volatile_ops (stmt) > > && (!gimple_clobber_p (stmt) > > || TREE_CODE (gimple_assign_lhs (stmt)) != MEM_REF)) > > return; > > > > ao_ref ref; > > if (!initialize_ao_ref_for_dse (stmt, &ref)) > > return; > > > > The check about clobber does not apply to calls and then it gives up on > > functions not returning aggregates (that is a common case). > > > > For functions returing aggregates it tries to prove that retval is dead > > and replace it. > > > > I guess I can simply call my analysis from the second return above and > > from the code removing dead LHS call instead of doing it from the main > > walker and drop the LHS handling? > > Yeah, something like that. OK, I will prepare updated patch, thanks! Honza > > Richard. > > > Thank you, > > Honza > > > > > > Thanks, > > > Richard. > > > > > > > + } > > > > else if (def_operand_p > > > > def_p = single_ssa_def_operand (stmt, SSA_OP_DEF)) > > > > {