From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id 63C983858C83 for ; Fri, 19 Aug 2022 16:02:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 63C983858C83 Received: by mail-pg1-x536.google.com with SMTP id f4so2185029pgc.12 for ; Fri, 19 Aug 2022 09:02:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=ybKTYILxse6XwhsBNwrN+8tMhowPE+yOwIjvvyHSFhs=; b=F4gNmzrT7pDrmOIOfNjw9R6OWk9Dvs7aY6dSx3QRWnIf5pRJmxIGyCAl5iJALdVLtD glsf3tUg4x3YzRrjFZ9KfM9TWqUXnQ1VSGhFAWfAE0duHRal3sHtDJ6+DIxGu4bXDcoz BN4nVXBy6NcyjWu+q//1yekYrRZhFe2gOU1cuRfCKotrtJq/8J/uXxEj4WRgXhGiV08Z E4OGTYikj4cw6DNacKPQ/zAKT3T5DKQFNUDmQI/jFlIANk5bcaRbkk/P9ByHmtbct1VU nF8GoVXo6PhWalDeYJ6KZkrWVX6xCv+eLA5mkcE/AVj+/Om8+BEFVUhcPiocKABF7bY4 Qmzw== X-Gm-Message-State: ACgBeo0AZxHfNDecGJxRHeSeqcTAJmhOZFC83aUT+lRgeWG6S1cxmf7R UjTEtjKx75KQRN4NofLa+FzMX2uoivQ= X-Google-Smtp-Source: AA6agR4zFT0wYTWRNGQpHLCDmlRFClo/1H8a8i35fvGphEKUQHrS4o8u6yzuRZwE075pYHuUR2WIOg== X-Received: by 2002:a63:6804:0:b0:422:1689:ed05 with SMTP id d4-20020a636804000000b004221689ed05mr6665941pgc.289.1660924934489; Fri, 19 Aug 2022 09:02:14 -0700 (PDT) Received: from [172.31.0.204] (c-73-98-188-51.hsd1.ut.comcast.net. [73.98.188.51]) by smtp.gmail.com with ESMTPSA id y135-20020a62648d000000b0052e6d6f3cb7sm3588214pfb.189.2022.08.19.09.02.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Aug 2022 09:02:13 -0700 (PDT) Message-ID: Date: Fri, 19 Aug 2022 10:02:12 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH] Refactor back_threader_profitability Content-Language: en-US To: gcc-patches@gcc.gnu.org References: <81970.122081610045900133@us-mta-26.us.mimecast.lan> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 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: Fri, 19 Aug 2022 16:02:18 -0000 On 8/17/2022 1:31 AM, Aldy Hernandez via Gcc-patches wrote: > I just have a few high level comments. > > On Tue, Aug 16, 2022 at 4:05 PM Richard Biener wrote: >> The following refactors profitable_path_p in the backward threader, >> splitting out parts that can be computed once the exit block is known, >> parts that contiguously update and that can be checked allowing >> for the path to be later identified as FSM with larger limits, >> possibly_profitable_path_p, and final checks done when the whole >> path is known, profitable_path_p. > I thought we were removing references to FSM, as they were leftovers > from some previous incarnation. For that matter, I don't think I ever > understood what they are, so if we're gonna keep them, could you > comment what makes FSM threads different from other threads? FSM refers to the initial implementation from Steve E. IIRC.  It was designed to handle threading backedges in a loop where the path out of the current iteration would tell us where a multi-way branch in the next loop iteration would go. During the integration of Steve's work it was recognized that the backwards walk was generally a better model and we started moving to the backwards based threader with the goal of removing the forward threader. There should be tests in the testsuite which validate that we haven't lost the key transformation.  ssa-thread-backedge.c and pr77445-2.c > The DOM threader has limits? I thought most of those limits were just > due to the fact that it couldn't determine long enough paths? Either > way, I like that we're merging the necessary forward threader bits > here, in preparation for its demise ;-). The forward threader has structural limitations due to its custom block copier and CFG update code as well as profitibility limitations. jeff