From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by sourceware.org (Postfix) with ESMTPS id 2128C3858294 for ; Fri, 5 Aug 2022 16:35:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2128C3858294 Received: by mail-pj1-x1034.google.com with SMTP id x2-20020a17090ab00200b001f4da5cdc9cso8814058pjq.0 for ; Fri, 05 Aug 2022 09:35:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=ighnd//ZjxcgcfJ5UqWhps4LsLp7AAi9VryUkRCmDqQ=; b=10JVL1HP/YtxhNywHjOz2AAlhtb9kaj6JOujpvhMX8o51viSf8zUWKh++wXnApLjvS QyTRVwVlRmh+GLpn9jvZOOLVzKlp+vUvLhfp1ynn96WTR7X1S2e6GqSHqV4UR+/kAH4g VTdxsd50+D+/epULnw5PJ5sSR4LhWEHrPaQ2QMnKnRn+CNnmt2cwRjvSg8zHlczeRHgm pcuUl+BWxFfYSqi9gWYSX2KL9gCnZQd1p1pd4i4SH2XthKF19MVtOUJkaXjSKIW7W1ay bgARQzGg/XsGRlcO14uQgG670xnIjSEGhCczNFVojK9aswR5w/lNPqbNsv/CnNaeueTY ng1A== X-Gm-Message-State: ACgBeo2Iovl3r1v6bMEJC4HwJht6SRyV8j04bz1A5q3HxMyjuuMnUo/q sW2duFxmbvW9N/EgrSmh0b8jCtBhbgc= X-Google-Smtp-Source: AA6agR6HHKIYfXPHvdR6afpI/7gS/6ZsDuczxP9S2usX51ya87T2RudePNW5Bofw5LGT1gh5txoxwA== X-Received: by 2002:a17:90b:1c8e:b0:1f1:b5a9:20c3 with SMTP id oo14-20020a17090b1c8e00b001f1b5a920c3mr8672091pjb.47.1659717313381; Fri, 05 Aug 2022 09:35:13 -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 s4-20020a17090a760400b001f280153b4dsm5779100pjk.47.2022.08.05.09.35.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Aug 2022 09:35:12 -0700 (PDT) Message-ID: Date: Fri, 5 Aug 2022 10:35:11 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] Properly honor param_max_fsm_thread_path_insns in backwards threader Content-Language: en-US To: gcc-patches@gcc.gnu.org References: <20220802130109.AD89F385381B@sourceware.org> From: Jeff Law In-Reply-To: <20220802130109.AD89F385381B@sourceware.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00, BODY_8BITS, 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, 05 Aug 2022 16:35:16 -0000 On 8/2/2022 7:00 AM, Richard Biener via Gcc-patches wrote: > I am trying to make sense of back_threader_profitability::profitable_path_p > and the first thing I notice is that we do > > /* Threading is profitable if the path duplicated is hot but also > in a case we separate cold path from hot path and permit optimization > of the hot path later. Be on the agressive side here. In some testcases, > as in PR 78407 this leads to noticeable improvements. */ > if (m_speed_p > && ((taken_edge && optimize_edge_for_speed_p (taken_edge)) > || contains_hot_bb)) > { > if (n_insns >= param_max_fsm_thread_path_insns) > { > if (dump_file && (dump_flags & TDF_DETAILS)) > fprintf (dump_file, " FAIL: Jump-thread path not considered: " > "the number of instructions on the path " > "exceeds PARAM_MAX_FSM_THREAD_PATH_INSNS.\n"); > return false; > } > ... > } > else if (!m_speed_p && n_insns > 1) > { > if (dump_file && (dump_flags & TDF_DETAILS)) > fprintf (dump_file, " FAIL: Jump-thread path not considered: " > "duplication of %i insns is needed and optimizing for size.\n", > n_insns); > return false; > } > ... > return true; > > thus we apply the n_insns >= param_max_fsm_thread_path_insns only > to "hot paths". The comment above this isn't entirely clear whether > this is by design ("Be on the aggressive side here ...") but I think > this is a mistake. In fact the "hot path" check seems entirely > useless since if the path is not hot we simply continue threading it. I think the intent here was to allow more insns to be copied if the path was hot than if it was not not hot.     But the logic seems a bit convoluted here. jeff