From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 36B4B3857B9D for ; Thu, 22 Sep 2022 07:44:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 36B4B3857B9D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 13D162198D; Thu, 22 Sep 2022 07:44:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1663832652; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wJNs1sCdjwuPP9OSFjFNIW51GV3sQ7r6vT0V53sBWhQ=; b=iQMxNgXLDCvGkw0IqJ93P6ujfK6wRNsX6wQVIP4rjTZAXpW3BtKnO85jTEcABTHfV3NRie Dm9H7D+o5sfvx52GOnM2n5W/ZtG0jk5NRDMrZG8xtV66OMTaUIdhZdttudBKV2ZrnLD0wd zb16XoZ8uloLsLzIfD46sSgmKXcfHfI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1663832652; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wJNs1sCdjwuPP9OSFjFNIW51GV3sQ7r6vT0V53sBWhQ=; b=qQSFCoaDbKT9cMYGyYG3VLjtq4qVBPmwohOM355IUYLX8owdotpnKoql9G68mvon7SNevd EMUpasiAoAEYKUAQ== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id E2F8B2C141; Thu, 22 Sep 2022 07:44:11 +0000 (UTC) Date: Thu, 22 Sep 2022 07:44:11 +0000 (UTC) From: Richard Biener To: Ju-Zhe Zhong cc: gcc-patches@gcc.gnu.org, richard.sandiford@arm.com Subject: Re: [PATCH] DSE: Enhance dse with def-ref analysis In-Reply-To: Message-ID: References: <20220922070625.7197-1-juzhe.zhong@rivai.ai> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 22 Sep 2022, Richard Biener wrote: > On Thu, 22 Sep 2022, juzhe.zhong@rivai.ai wrote: > > > From: Ju-Zhe Zhong > > > > This patch fix issue: PR 99407 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99407 > > > > The enhancement implementation is simple: > > 1.Search gimple statement in program reverse order. > > 2.Queue the store statement which may be possible kill the def > > of previous store statement. > > 3.Perform dse_def_ref_analysis to remove stores will not kill > > any def. > > For example: > > a[i_18] = _5; > > ... > > foo (&a); > > a[i_18] = _7; > > > > a[i_18] = _7 is queued at the begining and will be removed > > in dse_def_ref_analysis. > > 4.Remove the store if the def is confirmed to be killed. > > But we already do the very same thing in dse_classify_store, I fail > to see why we need to have an alternate implementation? It also > seems to be quadratic in the size of a basic-block? > > The issue with dse_classify_store is that it relies on > ref_maybe_used_by_stmt_p but that doesn't handle > > a[i] = ..; > .. = a[i+1]; > > but when seeing a[_1] vs. a[_2] (two variable offsets), it gives > up, asserting may-aliasing. We do have infrastructure to catch > such cases with data reference analysis. If we want to catch > these cases we should use that instead. Given we have a > DSE/DCE pass pair right before loop optimizations we could even > move those inside of the loop pipeline and perform this more > expensive checks conditional on loop/scev availability. Oh, and when doing non-loop aware analysis we don't need SCEV. The following optimizes the testcase but as said I don't think we want to perform this for each of the DSE passes since it can be somewhat expensive, at least without doing more caching (we could keep a stmt -> data-ref hash-map and compute data-refs at most once for each statement, that would make it more acceptable). Richard. >From 515b213e9d06c2bd36160e66728f57e48095bb84 Mon Sep 17 00:00:00 2001 From: Richard Biener Date: Thu, 22 Sep 2022 09:40:40 +0200 Subject: [PATCH] tree-optimization/99407 - DSE with data-ref analysis To: gcc-patches@gcc.gnu.org * tree-ssa-dse.c (dse_classify_store): Use data-ref analysis to disambiguate more uses. --- gcc/tree-ssa-dse.cc | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/gcc/tree-ssa-dse.cc b/gcc/tree-ssa-dse.cc index 34cfd1a8802..340a54f4105 100644 --- a/gcc/tree-ssa-dse.cc +++ b/gcc/tree-ssa-dse.cc @@ -45,6 +45,8 @@ along with GCC; see the file COPYING3. If not see #include "ipa-modref.h" #include "target.h" #include "tree-ssa-loop-niter.h" +#include "cfgloop.h" +#include "tree-data-ref.h" /* This file implements dead store elimination. @@ -1019,6 +1021,25 @@ dse_classify_store (ao_ref *ref, gimple *stmt, /* If the statement is a use the store is not dead. */ else if (ref_maybe_used_by_stmt_p (use_stmt, ref)) { + if (is_gimple_assign (use_stmt)) + { + data_reference_p dra, drb; + dra = create_data_ref (NULL, NULL, ref->ref, stmt, + false, false); + drb = create_data_ref (NULL, NULL, + gimple_assign_rhs1 (use_stmt), + use_stmt, false, false); + bool alias_p = dr_may_alias_p (dra, drb, NULL); + free_data_ref (dra); + free_data_ref (drb); + if (!alias_p) + { + if (gimple_vdef (use_stmt)) + defs.safe_push (use_stmt); + continue; + } + } + /* Handle common cases where we can easily build an ao_ref structure for USE_STMT and in doing so we find that the references hit non-live bytes and thus can be ignored. -- 2.35.3