From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id AA52B385840A for ; Thu, 11 Nov 2021 13:20:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AA52B385840A Received: by mail-ed1-x534.google.com with SMTP id g14so24147909edz.2 for ; Thu, 11 Nov 2021 05:20:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OlIWJqj77lQB7H0QSJ+OHDEImEeoOodm7Xo0Z3iwADI=; b=P/F2oUxgcBQAyTFUxETtkQP4pq/lnC/5+Jxgf1tVmm4SQvIak/iHuMrDLmxr71zvHp hX6mgG727dR9HSx4t9cD6KWirm1hgtZVXwCSrZACrUQBcFv2EQxgL6XbDajvas1oGUCW 4Q27683Bu3TiIDFO7STy9z+V5LmOcwDlG1T8EdXY+LGM5no3kzhJkaedQKfn3PWAcceQ u8hxjccqc7Om1qGhd6i/WtA5nXPiG5gPZb4Z3yNh0y3STuz3PbB3M26AZcolWn9hH3UW B62vaCWt2Dj36MRlI7ZNtIZWTNqY4/ud3E0m2lvjfLugVb4DKBbVolIPgFBObfN+eERs f3bg== X-Gm-Message-State: AOAM532gMWh9rr5f+/cAmPdTP77wb5ugr2TS9ZKCziR8sUcGPpKDqe7e UFf3ZCWnUTDmFA+UO5khZcvrIfb6fRtcWDvLmGY= X-Google-Smtp-Source: ABdhPJzR5iZGHdWF8Z5C/AELdsYx1pVnFFvxnCKM7TLcd7XPKRfuVGIFce29s06PzhXh1UUM1Ai5LzX5QPQdATOy3/U= X-Received: by 2002:a17:906:388c:: with SMTP id q12mr9406475ejd.281.1636636843582; Thu, 11 Nov 2021 05:20:43 -0800 (PST) MIME-Version: 1.0 References: <20211110124316.GF97553@kam.mff.cuni.cz> <20211111120715.GC47134@kam.mff.cuni.cz> <20211111124243.GA17431@kam.mff.cuni.cz> In-Reply-To: <20211111124243.GA17431@kam.mff.cuni.cz> From: Richard Biener Date: Thu, 11 Nov 2021 14:20:32 +0100 Message-ID: Subject: Re: Use modref summary to DSE calls to non-pure functions To: Jan Hubicka Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 13:20:46 -0000 On Thu, Nov 11, 2021 at 1:42 PM Jan Hubicka wrote: > > 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? You mean handle a &decl argument specially for unknown param offset? Yeah, I guess so. > 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? for this case PTA should tell you the alias is to 'decl' only but then I'm not sure if stmt_kills_ref_p is up to the task to determine that 'decl = {}', from a quick look it doesn't. So indeed the only interesting case will be a &decl based parameter which we can special-case. > > > 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)) > > > > > {