From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by sourceware.org (Postfix) with ESMTPS id B7E1C3858D38 for ; Wed, 1 Feb 2023 07:52:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B7E1C3858D38 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-x130.google.com with SMTP id w11so27933131lfu.11 for ; Tue, 31 Jan 2023 23:52:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CayO8RvZFJCBkSDvLMqQ/KfiP9LuT87i6Ep6Wi3Re+8=; b=AlLnB3uTiQFsFfqehxYPRziVILNlO3dJORZarwmxHCCZTeYfGKgIjVKP4aIkC1RJ1W bV968hbbKssktzuyrb42aQrmUeL0F+ctAt9IS63re5J4mipnJHcrG/od+kriWcP0KmaI j4VCgV494LM+iHy/MioK2GGTLWEveg8wTcR4n7/HezFx2K2iYTya1CFPWgr5sjO+6vjs JRyMNPjQwOROLbnHykXaz3W1OG9978JXkEXR7f6+GbhL8tLUiQvxxV3B1Hi1mRXe/9Dw 0WH0RSybq0oZmnzDhDYzhPYdBMqWNw8TGyFRfB5XstIjcltC4tYwO+QrxI+EfT2wQIOS CNLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=CayO8RvZFJCBkSDvLMqQ/KfiP9LuT87i6Ep6Wi3Re+8=; b=buWd2jf979rE6IlDHoGbMPqFCuMkBiSnbWIgCGJWVCy1D7hiRgWuRmLprtKrmqbOrH /6HTN9QjoseSB+6lQTGIkPA91yBITMoiNTzCao15Xc8YuHQx5lVqzFVv1rXdw2TeBtHB r6wr0HQSJoi4TSVx6VRrp383Y0IEaAO3jb2Y52NjV8hswCJ3o88aGh/VPooMfQwOeAXD hGl/ThwJESoKQiQrbYxnJRrtcjIiCMbafP9WGcZkVfTF3DxszoxGhOZdg9nDE72ogjrh a5n4v9j9VX8NLhQgHTthaF1eTfd8xngggWzB1pn4apOKk8Xgb1/hYdfWKygx0ySkmA3E uoLw== X-Gm-Message-State: AO0yUKXJwBdp6FVkq/Dth+wZpReLsuUTXahKq316W1MOIkH6otoxHD67 PjkrMCmGmOdwgLvxR2H25fhsvENfnOXfsdfmH88= X-Google-Smtp-Source: AK7set8aLB1sV5ha//BeI6pVVy2hKWLjFCGXZRzvTa7q35eCfsgFocvS6UsSy78+4mcUriog+akqQRzUt32hmIa7A4o= X-Received: by 2002:a19:f514:0:b0:499:f8e4:6dd0 with SMTP id j20-20020a19f514000000b00499f8e46dd0mr170130lfb.162.1675237946061; Tue, 31 Jan 2023 23:52:26 -0800 (PST) MIME-Version: 1.0 References: <4edb00e2-4691-bdd4-1b4d-12e6b9983ad7@redhat.com> In-Reply-To: <4edb00e2-4691-bdd4-1b4d-12e6b9983ad7@redhat.com> From: Richard Biener Date: Wed, 1 Feb 2023 08:52:12 +0100 Message-ID: Subject: Re: [PATCH] PR tree-optimization/108356 - Ranger cache - always use range_from_dom when updating. To: Andrew MacLeod Cc: gcc-patches , "hernandez, aldy" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.1 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 Tue, Jan 31, 2023 at 9:11 PM Andrew MacLeod via Gcc-patches wrote: > > This turned out to be a more interesting problem than I wanted. > > the situation boils down to: > > > # g_5 = PHI <0(2), 2(8)> > if (g_5 <= 1) > goto ; [INV] > > : > if (g_5 != 0) > goto ; [INV] > else > goto ; [INV] > > : > c = 0; > > : > goto ; [INV] > > We globally know that g_5 is [0,0][2,2] > we also know that 10->4 , g_5 will be [0,0] > Which means we also know that that the branch in bb_4 will never be > taken, and will always go to bb 8. > THis is all processed in EVRP, the branch is changed, and the next time > VRP is called, we blow the block with c = 0 like we want... > > Unfortunately it doesnt happen within EVRP because when this updated > range for g_5 is propagated in the cache, it was tripping over a shotcut > which tried to avoid using lookups when it thinks it didnt matter, and > would occasionally drop back to the global range. > > In particular, the cache had originally propagated [0,0][2,2] as the on > entry range to bb8. when we rewrite the branch, we mark 4->7 and 7->8 > as unexecutable edges, then propagate the new range for g_5.. This > requires recalculating the existing range on entry to bb8. > > It properly picked up [0,0] from 4->8, but when the cache query checked > the range from 7->8, it discovered that no value was yet set, so instead > of looking it up, it fell back to the global range of [0,0][2,2]. If it > properly calculates that edge instead, it comes up with UNDEFINED (as it > is unexecutable) and results in [0,0]... and EVRP then also removes the > block is c = 0 in. > > By picking up the global value, it still thought 2 was a possibility > later on, and a single VRP pass couldn't eliminate the branch ultimately > leading to the store... it required a second one with the adjusted CFG > to catch it. > > This patch tells the cache to always do a read-only scan of the > dominator tree to find the nearest actual value and use that instead. > This may solve other lingering weird propagation issues. > > I also ran a performance run on this change. It does slow VRP by down > about 1%, but the overall change is nominal at around 0.05%. > > Bootstraps on x86_64-pc-linux-gnu with no regressions. OK? OK. Thanks, Richard. > Andrew >