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 69C143858437 for ; Tue, 19 Oct 2021 07:33:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 69C143858437 Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-320-AWj-D1mxOq6trCN4wv8yGg-1; Tue, 19 Oct 2021 03:33:32 -0400 X-MC-Unique: AWj-D1mxOq6trCN4wv8yGg-1 Received: by mail-lf1-f71.google.com with SMTP id z29-20020a195e5d000000b003fd437f0e07so1054975lfi.20 for ; Tue, 19 Oct 2021 00:33:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ElgD68ZKPb+uigt3W2zGe3ZEgOBwSaQC8bggZHiqBs0=; b=tfO/N8hC/R56J4MUN7BDfJ3XwUZow0RRd5UHOrUkalHZN2H4N0fZI2+euMBXNU/PH0 LhO0L8vhqCCjD95RNhUKhHyTjJXT00JSus25xW35XJcdVXvWcuuHnS8K/rzH7swS5kNq mkLcDI+7p1FMBiQ80yHM8bFD8WU5AE3DWO5vP9Uvkc5vqMc0m35+VLGcH+xotSUGmWpw l3IwzjSSzCsxspgm/eo4VkMCLtQ4OqE85MJ+zaFqCaW4mXbX+4E+CskbBv/fYu4GVe+3 pjgXCkHu/GtBFoPNLcBIwP1Agka/mIHqsylExSvLftEB9S9r9ciRyAixgtHHGLsfdPTN mJuA== X-Gm-Message-State: AOAM532TGjaSiRI5kyOdl9dw3PzstgIZ8PlKCH31wQv8Xqwbfl50Ju0X BpaV8H0aQbDDfXaLSQMP8d3IMcdKvr9EbQ38Xoc3JQuY5Nil8EHsyIBGpYsLUyFac4HKyawJshs U/noefgJxzUnawM0LVUymNAvUsSRmzbjTEg== X-Received: by 2002:a2e:9d89:: with SMTP id c9mr5104075ljj.125.1634628811439; Tue, 19 Oct 2021 00:33:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwIMSNzxjKdHSBfii6n4vAQlGqXO1+eG4GgX9wJjBAjYlX+eAEFqOTImV0CqRDDBGBTZH9sKF7lF9oFIeUYSZ0= X-Received: by 2002:a2e:9d89:: with SMTP id c9mr5104056ljj.125.1634628811203; Tue, 19 Oct 2021 00:33:31 -0700 (PDT) MIME-Version: 1.0 References: <20211018134117.410106-1-aldyh@redhat.com> <69d78e89-c086-d10c-901f-72f504aeb93f@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Tue, 19 Oct 2021 09:33:20 +0200 Message-ID: Subject: Re: [RFC] Remove VRP threader passes in exchange for better threading pre-VRP. To: Richard Biener Cc: Jeff Law , GCC patches , Andrew MacLeod X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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 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: Tue, 19 Oct 2021 07:33:35 -0000 On Tue, Oct 19, 2021 at 8:52 AM Richard Biener wrote: > > On Mon, Oct 18, 2021 at 4:03 PM Aldy Hernandez wrote: > > > > > > > > On 10/18/21 3:41 PM, Aldy Hernandez wrote: > > > > > I've been experimenting with reducing the total number of threading > > > passes, and I'd like to see if there's consensus/stomach for altering > > > the pipeline. Note, that the goal is to remove forward threader clients, > > > not the other way around. So, we should prefer to remove a VRP threader > > > instance over a *.thread one immediately before VRP. > > > > > > After some playing, it looks like if we enable fully-resolving mode in > > > the *.thread passes immediately preceeding VRP, we can remove the VRP > > > threading passes altogether, thus removing 2 threading passes (and > > > forward threading passes at that!). > > > > It occurs to me that we could also remove the threading before VRP > > passes, and enable a fully-resolving backward threader after VRP. I > > haven't played with this scenario, but it should be just as good. That > > being said, I don't know the intricacies of why we had both pre and post > > VRP threading passes, and if one is ideally better than the other. > > It was done because they were different threaders. Since the new threader > uses built-in VRP it shouldn't really matter whether it's before or after > VRP _for the threading_, but it might be that if threading runs before VRP > then VRP itself can do a better job on cleaning up the IL. Good point. FWIW, earlier this season I played with replacing the VRPs with evrp instances (which fold far more conditionals) and I found that the threaders can actually find LESS opportunities after *vrp fold away things. I don't know if this is a good or a bad thing. Perhaps we should benchmark three alternatives: 1. Mainline 2. Fully resolving threader -> VRP -> No threading. 3. No threading -> VRP -> Full resolving threader. ...and see what the actual effect is, regardless of number of threaded paths. Speak of which, what's the blessed way of benchmarking performance nowadays? I've seen some PRs fly that measure some more lightweight benchmarks (open source?) than a full blown SPEC. > > + /* ?? Is this still needed. ?? */ > /* Threading can leave many const/copy propagations in the IL. > Clean them up. Instead of just copy_prop, we use ccp to > compute alignment and nonzero bits. */ > > Yes, it's still needed but not for the stated reason - the VRP > substitution and folding stage should deal with copy/constant propagation > but we replaced the former copy propagation with CCP to re-compute > nonzero bits & alignment so I'd change the comment to > > /* Run CCP to compute alignment and nonzero bits. */ Ahh.. There's another similar comment after DOM. Is this comment still relevant? NEXT_PASS (pass_dominator, true /* may_peel_loop_headers_p */); /* Threading can leave many const/copy propagations in the IL. Clean them up. Failure to do so well can lead to false positives from warnings for erroneous code. */ NEXT_PASS (pass_copy_prop); /* Identify paths that should never be executed in a conforming program and isolate those paths. */ Thanks. Aldy