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 B7CBC3857802 for ; Fri, 22 Oct 2021 03:53:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B7CBC3857802 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-470-Zq1DlJTROQqGb3IBOtdAPg-1; Thu, 21 Oct 2021 23:53:50 -0400 X-MC-Unique: Zq1DlJTROQqGb3IBOtdAPg-1 Received: by mail-lf1-f71.google.com with SMTP id i6-20020a056512318600b003fd8c8c2677so1124314lfe.1 for ; Thu, 21 Oct 2021 20:53:50 -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=bWRvfGVgazK9q1D9rgA47bwf/MyT3wh6z2yzKZMb6BA=; b=ACw0FDtclxeZtP0ReELi3IwQ034aDcnaCX0+Z20I0cIvfgb5RyDvMlm2qinzDuxRTZ vLMN9pxLY30wa0F+u8mHfNkx1eNnysP0Aaf7FCj5YZwP8cpzoS1ZiVExhQOTA7U+u7pc HYT6VKiK5kLAtDkHkliMFTMCuzVBdkDu/Y+LoecAJ5QjOtLS+3WxLdhcZXE9MxkOnvJB z5+Sr20f7AFTAxZiovMN1KE3PgcfZudw2+f91ykg63T3p9IJNjInYHLIQq8YxmWUGNEh cuid8hJGOivQ6FXIvXpLNl4QeW04j0CKoTDrfOIrgD7AFVUrOBjJJoEzbM1V9+9dUtLg 2eDg== X-Gm-Message-State: AOAM533IuN/zIj5pJgAE3nH5Y3By8N3BdbXvQSFDmPcNzowxMpQB3W08 cCuf9BvaaLgHSVTMD5imEslBxCIqEMeY5iAOApYTmWr2Caujt9uPaEmJZHAWNZqctG6b8OUsswY IwdlXJ+cpQged/d84Vhqquald30SndltACQ== X-Received: by 2002:ac2:4285:: with SMTP id m5mr2716227lfh.86.1634874829117; Thu, 21 Oct 2021 20:53:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwfroZPwYxtx0jAFranTYAnEPAYbV9EwwtaTuLokpCqjzbaQTDcsBFhlR+MtZYHLFo4iwaxALDR9g5GbmeuUhA= X-Received: by 2002:ac2:4285:: with SMTP id m5mr2716208lfh.86.1634874828835; Thu, 21 Oct 2021 20:53:48 -0700 (PDT) MIME-Version: 1.0 References: <20211020102816.656714-1-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Fri, 22 Oct 2021 05:53:38 +0200 Message-ID: Subject: Re: [PATCH] Try to resolve paths in threader without looking further back. To: Jeff Law Cc: GCC patches , Andrew MacLeod , Martin Sebor X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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, 22 Oct 2021 03:53:55 -0000 On Fri, Oct 22, 2021, 05:34 Jeff Law wrote: > > > On 10/21/2021 4:15 AM, Aldy Hernandez wrote: > > On Wed, Oct 20, 2021 at 10:19 PM Jeff Law wrote: > >> So we want to keep some form of ssa-dom-thread-7. That' s the canonical > >> testcase for the case for the FSM optimization. > >> > >> What we need to verify is that we thread jumps across the backedge of > >> the loop through the switch statement to a particular case (thus > >> bypassing the indirect jump for the switch statement). How to do that > >> in a way that's easier to manage? I have no clue. I guess a gimple-fe > >> based test might help. > > Ah, I see. > > > > After lots of pain, I was able to distill a tiny testcase that does > > just that (tree-ssa/ssa-thread-backedge.c), and is easy to maintain. > > I've added a "backedge" marker to the path dumping code for easy > > matching in the test. An alternative would be to convert it to a > > gimple FE test examining the exact thread sequence through the > > backedge, but I think that's overkill since the test is so small. > Well, and the worry with a smaller testcase is reducing too far with the > result not really being representative of the issue. This actually > happened during the development of the FSM bits. I got a test from the > ARM guys, evaluated it and concluded it could be addressed with the > forward threader.... Then I did the implementation work. Once done > they said it didn't work and gave me a better testcase which had more > "join" blocks we would have had to copy to realize the important jump > threads. At which point Steve E's FSM threader was the only viable choice. > > > > > > Phew, I think we're finally converging on a useful set of threading > tests :). > > > > OK for trunk? > Mostly, I just worry about losing the key test for the FSM optimization. With the provided test, the forward threaders can't thread through the backedge and into the switch. Disabling the other threaders was just a precaution. I just wanted to make sure it happened late because of the loop restrictions we have in place. I could enable the forward threaders to prove they can't get it. Also, we have an assert noting that we never thread through backedges in the forward threaders. It was part of the refactor. So the forward threaders can't even do it. I could add more cases and check that we have N or more threads through the back edges. .and if it makes you feel safer, we could even convert the test to gimple and test the specific thread sequence. It's just that the gimple FE test is bound to get large and difficult to decipher if I start adding many switch cases. I'm just trying to avoid a huge test with 40 potential threads where no one really knows how many we should get....as every threading pass opens up possibilities for other passes. Ughhhh....we could put the test back, check for some random large number, and come up with a more satisfactory test later? ;-) Aldy