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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id BD7893855005 for ; Tue, 27 Jul 2021 16:22:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BD7893855005 Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-369-pJac-8vvP9-U2Co6KRifGg-1; Tue, 27 Jul 2021 12:22:02 -0400 X-MC-Unique: pJac-8vvP9-U2Co6KRifGg-1 Received: by mail-wm1-f70.google.com with SMTP id 25-20020a05600c0219b029024ebb12928cso1569478wmi.3 for ; Tue, 27 Jul 2021 09:22:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Qwe1mahADJ+wimYQLrqZU/LVnX4t4MpFjBD+Zy3AdpY=; b=sbHQ2txpqffhbmLL9f6IklgLF5lqAgcdoIA0caSKsrXyJbYDq0rcKpH7vDyv8jVDBm 9Z5It42ah5vTP35KCPR3cpOGEeiwBcEvwp/uC8kRd1l/0LSkvl5HYZzp+SwlqXE7/D4P BwhVeVXmsU63h14FUyQ0NPyoZ+OMszAffFZMjK7Gz0HJpSwp8osXIvOVVkfV06Z9xdzQ DmWIZlDXMbKfMJQoVsMz34ap7EH/Z2zyZuRDcrcjEG8NcK0vpvXg+utV8Cye9yqH622l F6zB3dnSUONV+8VPAY4Z2vmkynvWrmRkZVKGVl5TXKxvVFqXX2yKDhKfzoqmIo8S1Dbr kaHw== X-Gm-Message-State: AOAM530CVuJ1TzaS3xnz8gHsxci0Do84Kw4S5gxtKuqq3JwGhimod7w3 za+9XT0hRTYTQ/iRXleQ1TqdZv7tESgRZ1tRc1HftICteJlHUGe+/FvWKZqThdqsmLUzaf3PfvY gdZHS5Yfbba51O9vmCg== X-Received: by 2002:a1c:5449:: with SMTP id p9mr1463254wmi.101.1627402921124; Tue, 27 Jul 2021 09:22:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwYIRBdMGevbRS9sb9guFTDonQ3S7RTwqejiexydjw+l3nD5B55R++0PGUlycEWr8OCCSOcug== X-Received: by 2002:a1c:5449:: with SMTP id p9mr1463237wmi.101.1627402920869; Tue, 27 Jul 2021 09:22:00 -0700 (PDT) Received: from abulafia.quesejoda.com ([95.169.238.86]) by smtp.gmail.com with ESMTPSA id a8sm3736423wrt.61.2021.07.27.09.22.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jul 2021 09:22:00 -0700 (PDT) Subject: Re: [PATCH] Abstract out (forward) jump threader state handling. To: Jeff Law , GCC patches References: <20210727101914.2457023-1-aldyh@redhat.com> From: Aldy Hernandez Message-ID: <04b1002b-6849-1876-97c6-13845073f1ff@redhat.com> Date: Tue, 27 Jul 2021 18:21:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no 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, 27 Jul 2021 16:22:09 -0000 On 7/27/21 5:15 PM, Jeff Law wrote: > My recollection is there's also a case where the location of the state > push/pops are highly unintuitive.  I always meant to put in some sanity > checking on the push/pops, then go back and bring some sanity to that > code as well.  The one time I recall trying to clean this up (without > the sanity checking) I mucked it up badly -- and the only symptom was we > just started missing various jump threading opportunities ;(  Mentioning > it for awareness. Yes, I noticed that things were somewhat tricky. For instance, the caller (DOM / VRP) can also push and pop avails_exprs_stack/evrp/etc state, but I decided to ignore those since the threader only cares about the threading candidates it's considering. My ulterior purpose for this patch is to have a set of blocks / edges that indicate a path, and pass those to the jump threader simplify callback. In doing this I also found that the edges are not the only information denoting a path. We also have (some) blocks pushed into the jump_thread_edge (at least the EDGE_*COPY_SRC_BLOCK ones). I will be adding the capacity to add those in a follow-up. And yes it's been somewhat painful. What I've been doing is plugging into the evrp use in DOM threader, and making sure that the my follow-up changes to the path solver can simplify all the conds/switches that the DOM/VRP threader simplifier can handle. Ughhh, did any of this make sense? I manage to even confuse myself while explaining it :). > > OK and thanks so much for cleaning this up. NP. Thanks for reviewing them! Aldy