From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by sourceware.org (Postfix) with ESMTPS id 947D43858409 for ; Wed, 20 Oct 2021 20:01:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 947D43858409 Received: by mail-pj1-x102f.google.com with SMTP id ls18so3242450pjb.3 for ; Wed, 20 Oct 2021 13:01:34 -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=LU4p0hzwyO63mCwlLpKcO9XMRvNrjXa9QTaxzGQTYqs=; b=1q7SfQlmmjj9WyRbK003EXfT5KGpggR+GxBVsSVrqIV4HPlyNKYanIBuTANx+Bfk4s sztFZfbYsB7lbr9TD8734jpcCwfwj2VC8309SDvD408x4KJdP/QBqQmxLKrdOo959Tvv b+VoAPYOH+EqFaOtipzROHmDaXk+Y1cIsdc8yaMOGfUOLtQkYyS/lBnMI0Jo9WrKg8l9 q9vv4C79xFth5iySvtfGGbVZJKUcMez7gWWvUroHpQ8l3owlxn1SPR+Kf2kJNIjSYvUk 8Wl3OgjJWXTv/kUEymWO0Mz+JP72E8resgiTYmUHiHCTdzpIWAyMnpTlP0CpYUffQL7p ICkQ== X-Gm-Message-State: AOAM5315GFUH92aAdPyZykikolaK0pfoGV/11eJqx3Xr7auBw/kfa/bi WGWr4w2RATSoXkfnYTpZbuM= X-Google-Smtp-Source: ABdhPJz8Lm8htTc6EeFUYE8Kz/5CZvhRKnzS985IdX7+qR2FNjIrVMiUt3dotaatHIrAEztszEINkA== X-Received: by 2002:a17:90b:3687:: with SMTP id mj7mr1273133pjb.196.1634760093527; Wed, 20 Oct 2021 13:01:33 -0700 (PDT) Received: from [192.168.1.24] (65-130-88-192.slkc.qwest.net. [65.130.88.192]) by smtp.gmail.com with ESMTPSA id x184sm3338082pfc.44.2021.10.20.13.01.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Oct 2021 13:01:33 -0700 (PDT) Subject: Re: [PATCH] Try to resolve paths in threader without looking further back. To: Aldy Hernandez , Martin Sebor Cc: GCC patches , Martin Sebor References: <20211020102816.656714-1-aldyh@redhat.com> <555af8e5-d068-4bf3-23ef-1041f5f7259c@gmail.com> From: Jeff Law Message-ID: Date: Wed, 20 Oct 2021 14:01:31 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, 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-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: Wed, 20 Oct 2021 20:01:36 -0000 On 10/20/2021 9:15 AM, Aldy Hernandez wrote: > On Wed, Oct 20, 2021 at 4:35 PM Martin Sebor wrote: > >> I appreciate the heads up. I'm happy that the threader has >> improved. I'm obviously not pleased that it has led to regressions >> in warnings but I understand that in some cases they might be due >> to limitations in the warning code. I think the test case you have >> xfailed might be one such example. The uninitialized warnings are >> exquisitely sensitive to these types of changes. If/when this patch >> is applied please reopen PR 89230 and reference this commit. >> >> Having said that, to maintain the quality of diagnostics, >> the work that goes into these nice optimizer improvements needs >> to be balanced by an effort to either update the warning code >> to cope with the IL changes, or the optimizers need to take care >> to avoid exposing undefined code that the warnings are designed >> to detect. I'm concerned not just that the quality of GCC 12 >> diagnostics has been eroding, but also that it seems to be not >> just acceptable but expected. > You make a very good point. It is certainly not my intention to make > life difficult for the warning maintainers, but I'm afraid I don't > have sufficient knowledge in the area to improve them. > > There may be some low hanging fruit though. At least in the warnings > that use the ranger, there's no reason to run these passes so late in > the pipeline. You could run the warning code as early as you want, > insofar as SSA is available and the CFG has been built. Heck, you may > even be able to run at -O0, though we may need some sort of value > numbering. I believe Richi even suggested this a while back. Running them later in the pipeline is to take advantage of the optimizers removing dead and unreachable code as much as possible. In fact, that's critical to -Wuninitialized.  Optimizing away unreachable paths  to avoid Wuninitialized false positives has been the major driver of jump threading improvements for the last 15 years. jeff