From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id 74A3F3858D3C for ; Sun, 24 Oct 2021 16:57:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 74A3F3858D3C Received: by mail-pl1-x62c.google.com with SMTP id r5so1698908pls.1 for ; Sun, 24 Oct 2021 09:57:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=IsGGMCZp4+FloX1LZhxzBaUNoyMZkO/1bXynSye3EGE=; b=Z5VwpIhTcEq2BjXyZs7O7pnL1arPBs7WPxvRLqiDEXqMhM0TCnqiBkuhpfi/Ljnfp8 qAJrblCMSiZ4EQ3uN5SxmLd9/rsegTMNveQiXzYsTyHZlR6yco3NGurS3xJ2uJ9WqY8z lniid42EqTdMbyx9sRDQNRusybXMaJVjIbmNhPbbbTo4rUhjNeYERebLjn1/iQmxxUg3 f8jGJjuUAX+uxMTmuti0d1WEPDAunbxE5oLEDzVPuaX8358z+4FqlGHbfijJMivFlVQ4 xiNQ/pAg5OV0swiBmyTXxcEu6DY/OPuO5nt2cmAyX3T261OQ8xUdEIUrYLWCR3sRp9fS VaWw== X-Gm-Message-State: AOAM532cnPdjh0XHphvV/jzI4WgLKuGBk/KVI3RL5b6YkTG1R0VDq7aD aG/aTxvfCltVXp5XQRN+3Hc= X-Google-Smtp-Source: ABdhPJzIXJhY1bOHynbzEv/WKED8inTj8/hZZYL6My9f9gR+60qKzeokX131hjYstt6eO5mOopLbWw== X-Received: by 2002:a17:90b:4ac1:: with SMTP id mh1mr14521312pjb.144.1635094627230; Sun, 24 Oct 2021 09:57:07 -0700 (PDT) Received: from [172.31.0.175] (c-98-202-48-222.hsd1.ut.comcast.net. [98.202.48.222]) by smtp.gmail.com with ESMTPSA id f9sm5300288pju.48.2021.10.24.09.57.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 Oct 2021 09:57:06 -0700 (PDT) Subject: Re: [PATCH] Try to resolve paths in threader without looking further back. To: Aldy Hernandez Cc: GCC patches , Andrew MacLeod , Martin Sebor References: <20211020102816.656714-1-aldyh@redhat.com> From: Jeff Law Message-ID: <4c5533a3-7b11-a387-f519-9d90a0638c97@gmail.com> Date: Sun, 24 Oct 2021 10:57:05 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, NICE_REPLY_A, 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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Sun, 24 Oct 2021 16:57:10 -0000 On 10/21/2021 9:53 PM, Aldy Hernandez wrote: > > > > > > Phew, I think we're finally converging on a useful set of > threading tests :). > > > > OK for trunk? > Mostly, I just worry about losing the key test for the FSM > optimization. > > > With the provided test, the forward threaders can't thread through the > backedge and into the switch. Disabling the other threaders was just a > precaution. I just wanted to make sure it happened late because of the > loop restrictions we have in place. I could enable the forward > threaders to prove they can't get it. Right.  There was a time when the forward threaders handled the backedge, but it's much better handled by the backwards threader. > I could add more cases and check that we have N or more threads > through the back edges. .and if it makes you feel safer, we could even > convert the test to gimple and test the specific thread sequence. It's > just that the gimple FE test is bound to get large and difficult to > decipher if I start adding many switch cases. I would love if we could turn the testcase into a gimple based test.  I just shudder at the thought of trying to pull that together.  And yes, it's awful hard to decipher, both in terms of test behavior and in terms of what the key jump threads are. > > I'm just trying to avoid a huge test with 40 potential threads where > no one really knows how many we should get....as every threading pass > opens up possibilities for other passes. Understood.  To some degree it's inherent in the problem.  The smarter our threaders get the more likely they are to discover new opportunities, so there's clearly a maintenance burden to these tests over time.  It's made worse by the interactions with BRANCH_COST as well as the heuristics for switch conversion. Gimple based tests would significantly help the the latter issues, but I don't know how to tackle the problem of exposing more jump threads as our threaders get better. > > Ughhhh....we could put the test back, check for some random large > number, and come up with a more satisfactory test later? ;-) I thought our "counting" based tests could only check equality (ie, expect to see this string precisely N times).  Though if we could check that # threads realized was > some low water mark, that'd probably be better than what we've got right now. jeff