From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id A865D3858D35 for ; Thu, 20 Jan 2022 08:42:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A865D3858D35 Received: by mail-ed1-x52b.google.com with SMTP id m4so25364417edb.10 for ; Thu, 20 Jan 2022 00:42:13 -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=dIg48jpKJCZFJNt2xyQudXdVMaqOkySRrWxRzgFOBuo=; b=rCxyetoGajzxxdzMYXonX0rF3d74dnJmfSs3od8l2i/cxKGh2+40fzJ8wde3MVEujW eRSPm6mzSol9huOqrfyhdNxzD5bFpH8KNHdl+betvUopequfZhIzhxjk43J23p4oBu+M j3ZQTqY5FjeJmMG1ketSROy/L86xgru54URaEnRuCJ+ZEbUs5slZ1G+JREODz7T6X3jV 1ThaE41Ges3gCCopCpKGoeocUVov3HuQLaQBX4NJPK3ELEHuOUXd35+aujmkQ3BeyFBu zexzqXXExz7uhX/r5a2UCjvMcegYqeWqvV3JP0INaILM5vXTfNwkGsdoJ4T0q3atUwoY JJmw== X-Gm-Message-State: AOAM532SAPjsx1S5Cr/99tBqaMgznInRG6TKlHwZAu3DDJexYgx3NyS8 32aD++LFMJfsQT/Xp+CIik/Atm/c3YLemKX3r5k= X-Google-Smtp-Source: ABdhPJy3dFta45N/v9A3QdASeYsxGM0MFQxLYso6mjEfBkRDFlxTkAeH8M5K8SVFwGdIO4w/UYUgcUZZMkhouJpYHlk= X-Received: by 2002:a05:6402:2552:: with SMTP id l18mr34967481edb.124.1642668132442; Thu, 20 Jan 2022 00:42:12 -0800 (PST) MIME-Version: 1.0 References: <79a04182-b37f-0074-20f7-7ebf2aef197c@redhat.com> In-Reply-To: From: Richard Biener Date: Thu, 20 Jan 2022 09:42:01 +0100 Message-ID: Subject: Re: [PATCH] tree-optimization/103721 - Only add equivalencies that are still valid. To: Andrew MacLeod 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, 20 Jan 2022 08:42:15 -0000 On Wed, Jan 19, 2022 at 7:41 PM Andrew MacLeod wrote: > > On 1/19/22 04:33, Richard Biener wrote: > > On Wed, Jan 19, 2022 at 2:37 AM Andrew MacLeod via Gcc-patches > > wrote: > >> > >> OK for trunk? > > OK. I don't quite understand how what you describe above works, it sounds > > a bit odd with respect to the idea that equivalences should be transitive but > The transitive check is what prevents us from having to find and update > all the equivalence sets when a name needs to be removed. we can simply > create a new equivalence with that name, and all the older equivalences > in the dom tree will no longer equate with it and are eliminated by the > query. With the nature of on-demand, its possible for equivalences to > get created in unexpected orders, and logging all the equivalences as > they are seen and leaving the final determination to query time seems to > be the easiest and most accurate way to get results. I suspect we miss > a few relations if we process things in a random order, but we > shouldn't get anything wrong. Ah, that's an interesting approach to solving this issue! > > I should note that forming equivalences from PHI nodes with backedges > > is not possible without being very careful since you will easily end up > > equating _1 and _1 from different iterations (and thus with different value). > > The dominator search version used by ranger won't create equivalences > from back edges normally because the back edge doesn't dominate the > block. The only time we could get an equivalence from a back edge would > be if all the other arguments to a PHI at the top of the loop were > undefined, or the same value as came in on the back edge > > ie > > top_5 = PHI would create an equivalence between > top_5 and val_6... but that's OK because it is just a copy then anyway. > > or > > top_5 = PHI > > This will create an equivalence between top_5 and val_6 in the loop, > until we reach the point where val_6 is defined, and then the > equivalence will get killed. its possible that might cause an issue in > a single BB loop, If I could reproduce that... let me experiment. In > which case I'll simply disable equivalences applied to PHIs if its > driven by just a back edge. > > I dont see any other way we can get an equivalence/relation from a back > edge with the oracle (other than what the threader does, it has its own > oracle extensions for paths) Thanks for the explanation. > Its on my task list to document the entire oracle mechanism for both > equivalences and relations in the next month or two. That would be welcome. Thanks, Richard. > > Andrew >