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.129.124]) by sourceware.org (Postfix) with ESMTPS id C0D68385843F for ; Fri, 29 Oct 2021 08:15:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C0D68385843F 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-147-y-UEUgcgMHGUeHDbwGjuPA-1; Fri, 29 Oct 2021 04:15:50 -0400 X-MC-Unique: y-UEUgcgMHGUeHDbwGjuPA-1 Received: by mail-lf1-f71.google.com with SMTP id f13-20020a056512228d00b003ffd53671d8so3170308lfu.14 for ; Fri, 29 Oct 2021 01:15:49 -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=DkUanfP0u3JQ6bl4IOzcI8qiS/7QJokAxTlULSU/UwY=; b=6HPAKg7JmH3idjypUpvwSXCQTYq+NcI7UdnmnTzf+miUYzG1iSb6CD0MuvJPbrEsII Hlvi36wc3wTRDUKP+uQ/j/L9l1gOStqiNdZ8rHleXK/mFkG+DVolKy6g6Pq9PqkL/vj6 XGlf6qIkEt65g0vTTsg9sTxxuF3YNvSY+Dy7cU2ut3td33QIfrKCOUzsOFVeeOQlYFc+ fNAC63unw9gYhg6j2gp39ddjO5auhhDEmada1mpHanJSrXwhrA7LoT1aAwLOuZWuRICX CWdZWBi8ZypX4e/qjGIDpdHwMCvOrmPG+kreLz8DJAVDeA3nDoG/lJPbXH7J9E7L5gY4 U2tw== X-Gm-Message-State: AOAM532QZLjwyxR8w+uvucYTFvWQ00s3TY12j22D1VxO+GU6O/JTGcNN OD+KDOKURwdqibU7I6HY7J0+vKp+vRXxclIle9fwADkOmTBha0SX79qcrl+/k9JM2Wr1fRyUN6+ KPWBkPyZT5DnCvzcg4tLiOqrLQe5cfZ7wbQ== X-Received: by 2002:ac2:5c5e:: with SMTP id s30mr9004718lfp.445.1635495348674; Fri, 29 Oct 2021 01:15:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwXZFBSF8vkVvpNTAshf6xlk6Nm2G9G/bJ9jjVWi73ya5YnUnlx5B5tfefMCc7lw9pXmoyJidx6XwOtRrCu3ZM= X-Received: by 2002:ac2:5c5e:: with SMTP id s30mr9004691lfp.445.1635495348386; Fri, 29 Oct 2021 01:15:48 -0700 (PDT) MIME-Version: 1.0 References: <20211028152446.522454-1-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Fri, 29 Oct 2021 10:15:37 +0200 Message-ID: Subject: Re: [PATCH] Remove VRP threader passes in exchange for better threading pre-VRP. To: Richard Biener Cc: Jeff Law , 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.8 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_H4, RCVD_IN_MSPIKE_WL, 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: Fri, 29 Oct 2021 08:15:53 -0000 On Fri, Oct 29, 2021 at 10:10 AM Richard Biener wrote: > > On Fri, Oct 29, 2021 at 10:06 AM Aldy Hernandez wrote: > > > > On Fri, Oct 29, 2021 at 9:30 AM Richard Biener > > wrote: > > > > > Btw, in case the "fully resolving" mode is slower than not fully resolving > > > please consider gating it on -fexpensive-optimizations (aka -O2+), thus > > > run the passes in not fully resolving modes at-O1. > > > > Sorry for the awkward naming. I couldn't find a better name :-/. > > Suggestions welcome. > > > > The fast mode assumes any unknown ranges on entry to a path to be > > VARYING, whereas the fully resolving mode will ask the ranger, so the > > fully resolving mode will indeed be slower. Though, I haven't > > measured how much. However, we are gaining some time in total > > compilation speed (1.32%) by replacing two threaders with one. > > OK. Just again, -O1 is to favor compile-speed and should crunch through > those incredibly stupi^Wlarge machine-generated sources without problems. > But from your comment it doesn't sound like something completely unreasonable > or slow. It shouldn't be a problem. Andrew has worked hard at handling those large CFGs, and I'm just leveraging his work. The backward threader also has a limit of 10 blocks look-back. But if it becomes a problem, I'm more than happy to gate the fully resolving threader with fexpensive-optimizations, but we will lose threading ability at -O1. I assume that's OK? FWIW, Andrew has mentioned providing a fast mode for the ranger for precisely those huge CFGs. Perhaps when that's ready, we could use that mode for -O1. > > > > > > > Btw, there were quite a few big compile-time hogs with the vrp_threader > > > passes, not sure if this solves those. > > > > Sorry for not commenting on your spec ltrans report. I was waiting > > until this went in to get a better feel of whether it was the path > > solver, the forward threader, or something else. When I commit this > > patch we'll get the forward threader out of the set of variables to > > examine. The forward threader, for instance, has very few knobs > > limiting its behavior, and coupled with a smarter solver, who knows > > what's going on. > > > > It is possible we may need to add a few knobs (or re-add some of the > > ones I removed??), since the backward threader can find a whole slew > > of paths that the forward threader could never find. > > Yeah, sure. I'll wait unless this change is in and will re-measure and update > the PR. I'm working through a regression on ppc64, but I should be able to push later today. Thanks. Aldy