From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by sourceware.org (Postfix) with ESMTPS id 6C6B33858002 for ; Thu, 7 Oct 2021 13:35:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6C6B33858002 Received: by mail-qk1-x734.google.com with SMTP id m7so5918659qke.8 for ; Thu, 07 Oct 2021 06:35:22 -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=0+8Bw7IbVXPu10iPz7CGPnZuEFg+F5r+UMGuBqCmA6o=; b=1PHLCNs42cbYx7DZ/yTowSELfTxvwVQJdsQF5Rt+G0uxFnvLYSxvV8BkJcJaCvscPG glfusw2oBJhU0Lo/wDRFtYwMIORcgytMnapRt4eZ7AfacgGQPEQi3eyJ/87yxjRWYZLf DGrQ6cXCRmqJsKhAUsp3d9aq2Vd7DCW+/qJHGrkH+k3HeyylLaWJRYPp1P1VjfsjclG0 vVW9XRfFs2Ed+7OvLfWmNSlAdyTG/HGu+AnC0XTY94nWGb2KPyBT+CYEknup9oIgXHxM ZW2MJmkVvmB6ppBPMN2F0b5X4Y43Hrc17y3bKM6+W8ypoywqg8Jt4GHQ1Yfjh0XTrm1+ o0mw== X-Gm-Message-State: AOAM533aM1/3Jxe2c0Tdokbw4SzLrRflbQJzHT4FtDGXUxn+DYes9XOB MW/+JlpkOMIop2bB1++d/k1xqcvGUVI= X-Google-Smtp-Source: ABdhPJwxdeRrA/KaL85R+8vMAxAZbd+XDuUcf3MISX2rdUx2QgLA6tljaIPA2WcM85D59Lr9HLK1iA== X-Received: by 2002:a05:620a:49d:: with SMTP id 29mr3338122qkr.518.1633613721638; Thu, 07 Oct 2021 06:35:21 -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 b129sm3499396qkf.121.2021.10.07.06.35.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Oct 2021 06:35:21 -0700 (PDT) Subject: Re: [RFC] More jump threading restrictions in the presence of loops. To: Aldy Hernandez , Andreas Schwab Cc: Martin Sebor , Michael Matz , Aldy Hernandez via Gcc-patches References: <20211004094313.1596556-1-aldyh@redhat.com> <87ilyab8ft.fsf@igel.home> <2e178e1a-a72c-06fe-ff20-3ee38a50b34c@redhat.com> From: Jeff Law Message-ID: Date: Thu, 7 Oct 2021 07:35:17 -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: <2e178e1a-a72c-06fe-ff20-3ee38a50b34c@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.0 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-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: Thu, 07 Oct 2021 13:35:23 -0000 On 10/7/2021 2:15 AM, Aldy Hernandez wrote: > [Andrew, ranger comment embedded below.] > > On 10/7/21 1:06 AM, Jeff Law wrote: >> >> >> On 10/6/2021 7:47 AM, Aldy Hernandez via Gcc-patches wrote: >>> The pending patch I have from Richi fixes this.  Even so, it's the >>> uninit code that's confused. >>> >>> Sigh...every single change to the threading code shines the light on >>> some warning bug. >>> >>> If you take the calls.ii file from the aarch64 bootstrap and break on >>> the warning, you can see that the uninitalized use is for >>> const_upper_3934 here: >>> >>>   [local count: 315357954]: >>>    # const_upper_3934 = PHI >>>    if (_881 != 0) >>>      goto ; [50.00%] >>>    else >>>      goto ; [50.00%] >>> >>>    [local count: 157678977]: >>>    if (const_upper_3934 > _6699) >>>      goto ; [89.00%] >>>    else >>>      goto ; [11.00%] >>> >>>    [local count: 17344687]: >>> >>>    [local count: 157678977]: >>>    goto ; [100.00%] >>> >>>    [local count: 140334290]: >>>    stack_usage_map.481_3930 = stack_usage_map; >>>    _6441 = const_upper_3934 - _6699; >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> PROBLEMATIC READ HERE >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>    _4819 = stack_usage_map.481_3930 + _6699; >>>    __builtin_memset (_4819, 1, _6441); >>>    goto ; [11.00%] >>> >>> const_upper_3934 could be undefined if it comes from BB101 >>> (const_upper_3937(D)), but it only gets read for _881 != 0, so it >>> shouldn't warn. >>> >>> I suggest -Wmaybe-uninitialized be turned off for that file until the >>> warning is fixed. >>> >>> And yes, the proposed patch will also cure this, but the underlying >>> problem in the warning is still there. >> You haven't shown enough context for me to agree or disagree. Are >> there other preds to bb105?   I hate these slimmed down dumps.  I >> work better with the full pred/succ lists. >> -fdump-tree--blocks-details :-) >> >> It appears to me that for _881 != 0 we certainly flow into the read >> of _const_upper_3934 in bb103 and bb105.  Why do you think that's safe? > > My bad, there's some missing context. > > The only way to get to BB101->BB102 is through: > >   >   if (_6711 != 0) >     goto ; [5.50%] >   else >     goto ; [94.50%] > > And there's an implicit relation between _6711 and _811: > > > ... >   if (_6711 != 0) >     goto ; [5.50%] >   else >     goto ; [94.50%] > >   [local count: 17344687]: >   goto ; [100.00%] > >   [local count: 298013267]: > >   [local count: 315357954]: >   # _881 = PHI <1(87), 0(287)> > > That is, _6711 == !_881. > > [Andrew, it'd be neat if we could teach ranger the relationship > between _6711 and _811 above.  And also, that _881 is [0,1]. Perhaps > with the relation oracle, the uninit code could notice that a _6711 > guard is also a !_811 guard.] Ah, yes.  This is one of the most common cases where we fail to detect jump threads and/or fail to prune a path in the uninit warnings.  There's multiple instances of this BZ, though I don't have the #s handy and the testcases are much smaller & easier to understand.  I'm pretty sure they're linked to the meta bug for threading or uninit warnings. However, in this instance we may have a way out.   When we record the constant boolean equivalence for _881 talking the paths from 87 and 287 respectively, we could walk up the control dependency graph and derive other values such as _6711 in this example.  I'm pretty sure we don't have the CDG built for DOM, but I do think we have it in the predicate analysis engine, so we could at least prune the warning. Jeff