From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 6274C3858D1E for ; Wed, 17 Aug 2022 07:31:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6274C3858D1E Received: from mail-oa1-f70.google.com (mail-oa1-f70.google.com [209.85.160.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-16-ya85k5wsObWlLlfXvwgxlA-1; Wed, 17 Aug 2022 03:31:42 -0400 X-MC-Unique: ya85k5wsObWlLlfXvwgxlA-1 Received: by mail-oa1-f70.google.com with SMTP id 586e51a60fabf-11ba59dbdb5so2988584fac.18 for ; Wed, 17 Aug 2022 00:31:42 -0700 (PDT) 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; bh=0+QLUwHm2NCi6RIRIDIGNZtTvoPaZUULHqceLpU6Zlc=; b=cbMFWVMYfqsQlE3DSvWMK/sRg1heONa9MF/LSeLgBqeT+R992EZY++kmWyHdjcHWEx LtRk5VtlsxSXfo+R0B6RWryiPQp5KcT5DNyUFBbP4u5zbFcRmW9o1ONGukjvrtMwvWdL zksL2X/gyedg1hN/or3w0/Dc2YQmeCvXIovs9wyZlAgnH1ZwJgbODoXyrwai64PP7jig ZY5TzGL0FM16jlZ8Mnq0Clx+2Ajn1JslBDx9ms/y+fS6IGjvMnzman6Z42X0q4LQgtWa qIP4k8c1npVMROC6J98xNfILofH11X77w97UlNywWELJ6rW81/4DfXBraW5EwbhQVwra HZPg== X-Gm-Message-State: ACgBeo12wuqiLgwW93n2z9e/omPMX8bYVwWioUEkrnDCOxlMqOsgXiY1 AiwzBKVuD3Cg6jB0lhoY01oqshxavO42h8epjuCmThY9aZdX6+7gqfW+CZtjp3BkIsLP/WazLTK FGd7/gCIqlmBk2u9ZiJFb3V76+glvRVI73Q== X-Received: by 2002:a05:6808:f07:b0:344:7739:8e7b with SMTP id m7-20020a0568080f0700b0034477398e7bmr933637oiw.265.1660721501822; Wed, 17 Aug 2022 00:31:41 -0700 (PDT) X-Google-Smtp-Source: AA6agR7zJ3t1vENRTGkvAJFSPaLMOyP/VOXoLUuaXDWf5RRawCgLugRRSJgTIrT14IuKfPMqKgXBqfVCHzQwwdUhVVY= X-Received: by 2002:a05:6808:f07:b0:344:7739:8e7b with SMTP id m7-20020a0568080f0700b0034477398e7bmr933631oiw.265.1660721501591; Wed, 17 Aug 2022 00:31:41 -0700 (PDT) MIME-Version: 1.0 References: <81970.122081610045900133@us-mta-26.us.mimecast.lan> In-Reply-To: <81970.122081610045900133@us-mta-26.us.mimecast.lan> From: Aldy Hernandez Date: Wed, 17 Aug 2022 09:31:30 +0200 Message-ID: Subject: Re: [PATCH] Refactor back_threader_profitability To: Richard Biener Cc: gcc-patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, 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: Wed, 17 Aug 2022 07:31:46 -0000 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? In your possibly_profitable_path_p function, could you document a bit better what's the difference between profitable_path_p and possibly_profitable_path_p? > > I've removed the back_threader_profitability instance from the > back_threader class and instead instantiate it once per path > discovery. I've kept the size compute non-incremental to simplify > the patch and not worry about unwinding. > > There's key changes to previous behavior - namely we apply > the param_max_jump_thread_duplication_stmts early only when > we know the path cannot become an FSM one (multiway + thread through > latch) but make sure to elide the path query when we we didn't > yet discover that but are over this limit. Similarly the > speed limit is now used even when we did not yet discover a > hot BB on the path. Basically the idea is to only stop path > discovery when we know the path will never become profitable > but avoid the expensive path range query when we know it's > currently not. > > I've done a few cleanups, merging functions, on the way. > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > Statistics show an overall slight increase in threading but > looking at different files theres noise up and down. That's > somewhat expected since we now are applying the "more correct" > limits in the end. Unless I made big mistakes of course. > > The next thing cost-wise would be to raise the backwards > threading limit to the limit of DOM so we don't get > artificial high counts for that. 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 ;-). Looks good. Thanks. Aldy