From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 42BF23858D1E for ; Mon, 24 Apr 2023 13:51:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 42BF23858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1682344283; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aVmgRD/eBvAq703ESjymQcGidhI6aP+WOhzU317JLyg=; b=IVWzosb9fSJQdJTY4fKUFFjAqr6MqlRh0fgTyddhQkCs9UcrQCydg/ouH5aqZb9iUh+x37 PkC343l0j9aFkHPaUgcIGaIehYPmOTyQwBhqSRlbrPS3dYdWzBsb0ajzKYzLQQViRv+/sO ofGf0a1D/DXx5T0gVBJ8xlIVbDUv7lo= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-462-vMljBZo2OpmJoRSyot0K7Q-1; Mon, 24 Apr 2023 09:51:17 -0400 X-MC-Unique: vMljBZo2OpmJoRSyot0K7Q-1 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-74ab517c14bso1725505785a.1 for ; Mon, 24 Apr 2023 06:51:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682344277; x=1684936277; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aVmgRD/eBvAq703ESjymQcGidhI6aP+WOhzU317JLyg=; b=KZbFR2FWiP8J1Bj7Lui0EI93CcbpZVd8UYSQPalLEd3Wv43e+ZdexVKY1SsdnMhm9p lHCSahffEVZAwJqsvBaONctbPW5SqCPHOLIQtEbBWQTamRTPnsf0ShlCXAxLzkxxv6VH 5sQm8Z6GI1ZmJatZFtmp526RpPRDm188qfUHFFdN8MxbjJ8curM+AB5xDdXRhqlNomSS qVNStiIokULVw0cLQb8hxkUGtvCuaO2NZoSiY4mkIJC40/Ko68mFDkWmChf0OsnbOfTS Hp9IqibBn1Fo3/mbQHC13lMhbuls54m19jNWL7ZK2MB0e2AwsPes8V4tt1D1hit/1zn5 9iDg== X-Gm-Message-State: AAQBX9dPFQCX0Y7mfwxPxcJEvXMDq50AowhEE6huHdilI+TlRgi3uhkp N3Dem6cKS1sMOKOl9ePfvX3NfDVfAdn/tredLtUUQWIKqCUOytj70B6RcjKF3eTSRkqSd/vQm0s tiukYAGVWbW+aFcGunA== X-Received: by 2002:ac8:5716:0:b0:3ef:57e0:59a4 with SMTP id 22-20020ac85716000000b003ef57e059a4mr22625764qtw.23.1682344277053; Mon, 24 Apr 2023 06:51:17 -0700 (PDT) X-Google-Smtp-Source: AKy350bCOU+Py9C+Xt4UuLLP6H/dH/CYfgN8ONu4aDLU7VT7PGBF5dHckMVRcBuSKlerVljSb7Oq6g== X-Received: by 2002:ac8:5716:0:b0:3ef:57e0:59a4 with SMTP id 22-20020ac85716000000b003ef57e059a4mr22625734qtw.23.1682344276782; Mon, 24 Apr 2023 06:51:16 -0700 (PDT) Received: from ?IPV6:2607:fea8:51df:4200::1dcd? ([2607:fea8:51df:4200::1dcd]) by smtp.gmail.com with ESMTPSA id z26-20020ac87cba000000b003eb136bec50sm3593828qtv.66.2023.04.24.06.51.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Apr 2023 06:51:16 -0700 (PDT) Message-ID: <9c61bac0-b3ae-98e6-8abf-5a092db98f64@redhat.com> Date: Mon, 24 Apr 2023 09:51:15 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH] PR tree-optimization/109417 - Check if dependency is valid before using in may_recompute_p. To: Richard Biener , Jeff Law Cc: gcc-patches@gcc.gnu.org References: <428a4619-9653-ff0b-8092-25efc933ba80@gmail.com> From: Andrew MacLeod In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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 4/11/23 05:21, Richard Biener via Gcc-patches wrote: > On Wed, Apr 5, 2023 at 11:53 PM Jeff Law via Gcc-patches > wrote: >> >> >> On 4/5/23 14:10, Andrew MacLeod via Gcc-patches wrote: >>> When a statement is first processed, any SSA_NAMEs that are dependencies >>> are cached for quick future access. >>> >>> if we ;later rewrite the statement (say propagate a constant into it), >>> its possible the ssa-name in this cache is no longer active. Normally >>> this is not a problem, but the changed to may_recompute_p forgot to take >>> that into account, and was checking a dependency from the cache that was >>> in the SSA_NAME_FREE_LIST. It thus had no SSA_NAME_DEF_STMT when we were >>> expecting one. >>> >>> This patch simply rejects dependencies from consideration if they are in >>> the free list. >>> >>> Bootstrapping on x86_64-pc-linux-gnu and presuming no regressio0ns, OK >>> for trunk? >> eek. So you've got a released name in the cache? What happens if the >> name gets released, then re-used? Aren't you going to get bogus results >> in that case? Its not a real cache..  its merely a statement shortcut in dependency analysis to avoid re-parsing statements every time we look at them for dependency analysis It is not suppose to be used for anything other than dependency checking.   ie, if an SSA_NAME changes, we can check if it matches either of the 2 "cached" names on this DEF, and if so, we know this name is stale.  we are never actually suppose to use the dependency cached values to drive anything, merely respond to the question if either matches a given name.   So it doesnt matter if the name here has been freed > We never re-use SSA names from within the pass releasing it. But if > the ranger cache > persists across passes this could be a problem. See This particular valueswould never persist beyond a current pass.. its just the dependency chains and they would get rebuilt every time because the IL has changed. > flush_ssaname_freelist which > for example resets the SCEV hash table which otherwise would have the > same issue. > > IIRC ranger never outlives a pass so the patch should be OK. > > _But_ I wonder how ranger gets at the tree SSA name in the first place - usually > caches are indexed by SSA_NAME_VERSION (because that's cheaper and Its stored when we process a statement the first time when building dependency chains.  All comparisons down the road for staleness/dependency chain existence are against a pointer.. but we could simple change it to be an "unsigned int",  we'd then just have to compare again SSA_NAME_VERSION(name) instead.. > better than a pointer to the tree) and ssa_name (ver) will return NULL > for released > SSA names. So range_def_chain::rdc could be just > > struct rdc { > int ssa1; // First direct dependency > int ssa2; // Second direct dependency > bitmap bm; // All dependencies > bitmap m_import; > }; > > and ::depend1 return ssa_name (m_def_chain[v].ssa1) and everything woul if the ssa-name is no longer in existence, does ssa_name (x) it return NULL? > work automatically (and save 8 bytes of storage). > > Richard. >> jeff