From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) by sourceware.org (Postfix) with ESMTPS id 847413858405 for ; Fri, 10 Sep 2021 15:43:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 847413858405 Received: by mail-ot1-x32f.google.com with SMTP id i8-20020a056830402800b0051afc3e373aso2778673ots.5 for ; Fri, 10 Sep 2021 08:43:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=EQq5bctlxMGGaYWG4jUsnzGLvxTc87j2f2Rkc4YYMhc=; b=k/sK5ypYrb7JzuEPIdt+Tv/lVQnOKFLU5aMOiujmXy5DmSs04zOpvX9HjQkRjySYDS g6ZFZ00XztsUR+H0NUxLpwSfLibZQOAOZj/ulXRUhWqPvFmP9DiKPfunfKkHcn4f1bk1 d6dnXcyClrOJMrKFLPjBnanxKrghYQTr6A69vUx1TAOaQKvPoPY7ZTCFkeHnnpAn+C2b vtF47YglGKmhEZjSoUISbeSW8/7cizL5LWnlBD+zEP7TiVILVDGxzClJcGuocRgxOgHy SR2bRv25ehV+wf7jtRurzs7CJGaMNucElaim3GE1MCMi+2ZPlYDakUXq/NCmP+6JzA4f GDtw== X-Gm-Message-State: AOAM532q+NTQWlI1eHBCKZGZnFDp3GQAj1+MHGByI7MwM7V6o++1Mykj /8gzHqYjPoh57WF3KEbDuRo= X-Google-Smtp-Source: ABdhPJxgs+8Bm2BpqUQxK08MOnWCIVkisB4TtNlmYgkgzFR8CoweSck2MXWXx5zt+Ghh5iOtSS7BRw== X-Received: by 2002:a05:6830:31a5:: with SMTP id q5mr3478807ots.253.1631288590776; Fri, 10 Sep 2021 08:43:10 -0700 (PDT) Received: from [172.31.0.175] (c-98-202-48-222.hsd1.ut.comcast.net. [98.202.48.222]) by smtp.gmail.com with ESMTPSA id 4sm1237014ooa.11.2021.09.10.08.43.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Sep 2021 08:43:10 -0700 (PDT) Subject: Re: More aggressive threading causing loop-interchange-9.c regression To: Aldy Hernandez , Richard Biener Cc: Michael Matz , GCC Mailing List , Andrew MacLeod References: <09e48b82-bc51-405e-7680-89a5f08e4e8f@redhat.com> <6d5695e4-e4eb-14a5-46a6-f425d1514008@redhat.com> <07fdd2bb-e6b7-fe66-f6a0-df6ec0704ae4@redhat.com> <8c49db8d-3119-0dc2-2bbb-4062c8d5d53b@redhat.com> From: Jeff Law Message-ID: Date: Fri, 10 Sep 2021 09:43:06 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <8c49db8d-3119-0dc2-2bbb-4062c8d5d53b@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-2.2 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 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@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2021 15:43:13 -0000 On 9/9/2021 3:21 AM, Aldy Hernandez wrote: > >> >>    /* If this path does not thread through the loop latch, then we are >>       using the FSM threader to find old style jump threads. This >>       is good, except the FSM threader does not re-use an existing >>       threading path to reduce code duplication. >> >>       So for that case, drastically reduce the number of statements >>       we are allowed to copy.  */ > > *blink* > > Woah.  The backward threader has been using FSM threads > indiscriminately as far as I can remember.  I wonder what would break > if we "fixed it". ?!?  I'm not sure what you're suggesting here.  If you s/FSM threader/backwards threader/ in the comment does it make more sense?   The term FSM really should largely have been dropped as the backwards threader was improved to handle more cases. > >> >> so these cases should use the "old style" validity/costing metrics >> and thus >> classify threading opportunities in a different way? > > Jeff, do you have any insight here? This is precisely what you're cleaning up. > >> >> I think today "backwards" vs, "forwards" only refers to the way we find >> threading opportunities. > > Yes, it's a mess. > > I ran some experiments a while back, and my current work on the > enhanced solver/threader, can fold virtually everything the > DOM/threader gets (even with its use of const_and_copies, avail_exprs, > and evrp_range_analyzer), while getting 5% more DOM threads and 1% > more overall threads.  That is, I've been testing if the path solver > can solve everything the DOM threader needs (the hybrid approach I > mentioned). > > Unfortunately, replacing the forward threader right now is not > feasible for a few reasons: Right.  But I thought the short term goal was to replace/remove the forward threading from VRP.   Dropping from DOM is going to be tougher. > > a) The const_and_copies/avail_exprs relation framework can do floats, > and that's next year's ranger work. Right.  I'd actually run into this as well when I wanted to drop all the range bits out of DOM and rely exclusively on EVRP.   It'd still be a step forward to rip out the EVRP engine from DOM and simplify all the code that derives one equivalence from another so that it's only working on FP values. > > b) Even though we can seemingly fold everything DOM/threader does, in > order to replace it with a backward threader instance we'd have to > merge the cost/profitability code scattered throughout the forward > threader, as well as the EDGE_FSM* / EDGE_COPY* business. Right.  This is a prerequisite.  Though some of the costing will need to be conditional on the threader being used.  Refer back to the discussion around how the forward threader can commonize thread paths that lead to the same destination while the backwards threader can not. > > c) DOM changes the IL as it goes.  Though we could conceivably divorce > do the threading after DOM is done. The only reason threading runs in parallel with DOM is so that it can use the context sensitive equivalences.  With the infrastructure you're building, there's a reasonable chance we can move to a model where we run DOM (and in the long term a simpler DOM) and threading as distinct, independent passes. Jeff