From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by sourceware.org (Postfix) with ESMTPS id BE6A43858D28 for ; Tue, 11 Apr 2023 09:22:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BE6A43858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-x12c.google.com with SMTP id m4so9354416lfj.13 for ; Tue, 11 Apr 2023 02:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1681204939; x=1683796939; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0sQfmuxW68kaGeUkLT6I7OUw6SvoN3ZWo69qvwBDs2Y=; b=USXZQ/eslJpiqDf/43Ov6+aXgrYpUMHJW6i8hxcW4sSHeOZcBP0WM3oHfWr8OFo+oQ r/eK7sPWtMf2cQBDwlmqvUA329hm55bz05fXxA9UMcn8yatwaaWz0yxE0ZRUcU6ONhZl u4LFLlEcOqNuo0CekuywUuOaztlHG1lHbk0B7KSDVAPndTh06VAJVTow2Wmb3ZaJ8pgF sdr9jR5faeertAPtw0eHp9C50lnwTgRb3PS7oUX3qTY+kAV3kBx/vZkEl44C3qOgZ/Gc Z4c5hHISw0k8CflC6O/WtOwhpb/ftSLsdPlBW2GUcjHWRxPXgqJFmxyA00LVadYSu7FA F9sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681204939; x=1683796939; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0sQfmuxW68kaGeUkLT6I7OUw6SvoN3ZWo69qvwBDs2Y=; b=w7rfFShiI+8ximBV6XZfeVkotUlRCYpNoPN3wAaip9gcWwm2Ijq1yTgzlDfZVEmckK TGjeOgEcmflzN+0si+6MPf3mdkr4/nzfHX22s5yldxXykoQLa/VP+co3S+m7/RqYWQJJ F2UC2nCINPlwVSSDKcFCR6r2VE/lMPfYEZyjAKRYXmt8UcRSpgGzdOEtu2pMqEJUrtqY 7+ufAAx0UQmetsroiQQRRvw4KUpA5Tg0SHB2+xkq82qzaCb2pNxa7AKHTe96MvCeow+3 DcaCxhXf86Ge7ehc+ZMkLaBh9MLC9aZP7bjCxWyib8l6oHbElPPl5gprWpTk9DEEpt2N Nydg== X-Gm-Message-State: AAQBX9cn2LcAyj440rnvRsKTXiTTmTEDhmUD9SoNyVIOrNCeilCcvgmA 4P6rcqfa4o6nA1x1h/udeuAww0uo+CITHscN+ug= X-Google-Smtp-Source: AKy350ZoCEHYKc8tlsD/wkxInPDYWalt2wL62iABdEvKVaBSkRvqC8h1J2dZAdgU7GMp6tB7PbRNGRaX+jJRG98LTP8= X-Received: by 2002:ac2:4e42:0:b0:4e9:c027:5be6 with SMTP id f2-20020ac24e42000000b004e9c0275be6mr3863719lfr.12.1681204939154; Tue, 11 Apr 2023 02:22:19 -0700 (PDT) MIME-Version: 1.0 References: <428a4619-9653-ff0b-8092-25efc933ba80@gmail.com> In-Reply-To: <428a4619-9653-ff0b-8092-25efc933ba80@gmail.com> From: Richard Biener Date: Tue, 11 Apr 2023 11:21:22 +0200 Message-ID: Subject: Re: [PATCH] PR tree-optimization/109417 - Check if dependency is valid before using in may_recompute_p. To: Jeff Law Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Apr 5, 2023 at 11:53=E2=80=AFPM 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 dependencie= s > > 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 tak= e > > that into account, and was checking a dependency from the cache that wa= s > > in the SSA_NAME_FREE_LIST. It thus had no SSA_NAME_DEF_STMT when we wer= e > > expecting one. > > > > This patch simply rejects dependencies from consideration if they are i= n > > 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? 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 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 - us= ually caches are indexed by SSA_NAME_VERSION (because that's cheaper and 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 would work automatically (and save 8 bytes of storage). Richard. > jeff