From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id A9A7A3858D28 for ; Sat, 23 Oct 2021 21:32:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A9A7A3858D28 Received: by mail-pl1-x632.google.com with SMTP id s1so5181957plg.12 for ; Sat, 23 Oct 2021 14:32:15 -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:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=h2Iz0ioQqnzBFNN4aJwwSldusVMVlSmL1xxKdLcBudw=; b=LFtY7+YRndxh1vzLEzfBPOzUpJmg3qDms6nriUhMUe0xqeVwgwDBdDAxGZl8M0xp6q JSxV60PlMYDKbUknt68dWt/TAIeQChcnxMz5ylRFAi38hnvubC3cj1JR3OPU553Hrbac ilgnNBKY/yaxD/azEa3x8oECM6dgjpHqwu5eyCbxZqY50f26hoZuoCuCudhszX7MhVpe /HEATiiNbAECeVKK0XTAioiQD5Gzd8GQ8Uy9cLQR9InRSS+ck5v2bHtJIArjTDPvJ+Oo fsga8JIv1dm7ZrQ80KrKG8neuA7uETV/gzs1XR+RxOMLBBkhJ2XzBt8pOnp/BTspJHx7 Iqxg== X-Gm-Message-State: AOAM533TOdks6LpN/IS5uEA/Mmmi5qsJL+8vCwdOmA/OUhA7hj5+lixe qXXcHDCx+WScXMVodL6pDRc= X-Google-Smtp-Source: ABdhPJwEAKn1sHUKot39LUslZggbFnYigfneEiJDKiH+by2NFufYrJvYxSjEp+RenJrKgIWn0ueKbA== X-Received: by 2002:a17:90a:ba09:: with SMTP id s9mr9598792pjr.42.1635024734264; Sat, 23 Oct 2021 14:32:14 -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 v12sm13711622pjs.0.2021.10.23.14.32.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 23 Oct 2021 14:32:13 -0700 (PDT) Subject: Re: [PATCH] Convert strlen pass from evrp to ranger. From: Jeff Law To: Aldy Hernandez Cc: Jakub Jelinek , GCC patches , Andrew MacLeod , Richard Biener References: <20211008151222.37790-1-aldyh@redhat.com> <49371bdc-edd7-a5fa-4d75-9b2ed51478ad@gmail.com> <88f397a8-78d1-fe74-c221-e846072edff1@redhat.com> <49b035a6-7160-07d9-0c34-4accdebc1af4@gmail.com> <0fd10ec9-b993-3da7-b7b9-e9ca638a5d1b@gmail.com> Message-ID: Date: Sat, 23 Oct 2021 15:32:12 -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: <0fd10ec9-b993-3da7-b7b9-e9ca638a5d1b@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-1.9 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: Sat, 23 Oct 2021 21:32:17 -0000 On 10/21/2021 12:20 PM, Jeff Law wrote: > >> >>> So if we're referring to those temporary const/copy propagations >>> "escaping" into Ranger, then I would fully expect that to cause >>> problems.  Essentially they're path sensitive const/copy propagations >>> and may not be valid on all the paths through the CFG to the statement >>> where the propagation occurs >> Yeah.  disabling the global ranger should help, plus making sure you >> don't use the ranger in the midst of the path sensitive changes. > I think we should first try to remove those temporary const/copy > propagations.  As I noted in a different follow-up, I can't remember > if they were done as part of the original non-copying threader or if > they enabled further optimizations in the copying threader.  If its > the former, then they can go away and that would be my preference. > I'll try to poke at that over the weekend. OK.  So those temporary propagations are still useful.  Here's a simple example (pr36550, but there are others): [ ... ] ;;   basic block 3, loop depth 0, count 536870912 (estimated locally), maybe hot ;;    prev block 2, next block 4, flags: (NEW, VISITED) ;;    pred:       2 [50.0% (guessed)]  count:536870912 (estimated locally) (TRUE_VALUE,EXECUTABLE)   # VUSE <.MEM_10>   _20 = *argv_12(D);   if (_20 != 0B)     goto ; [70.00%]   else     goto ; [30.00%] ;;    succ:       4 [70.0% (guessed)]  count:375809640 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;                7 [30.0% (guessed)]  count:161061272 (estimated locally) (FALSE_VALUE,EXECUTABLE) [ ... ] ;;   basic block 7, loop depth 0, count 536763538 (estimated locally), maybe hot ;;    prev block 6, next block 8, flags: (NEW, VISITED) ;;    pred:       3 [30.0% (guessed)]  count:161061272 (estimated locally) (FALSE_VALUE,EXECUTABLE) ;;                4 [always]  count:375809640 (estimated locally) (FALLTHRU,EXECUTABLE)   # argv_32 = PHI   # bug_33 = PHI   # VUSE <.MEM_10>   _3 = *argv_32;   if (_3 == 0B)     goto ; [18.09%]   else     goto ; [81.91%] ;;    succ:       9 [18.1% (guessed)]  count:97100524 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;                8 [81.9% (guessed)]  count:439663014 (estimated locally) (FALSE_VALUE,EXECUTABLE) So when we reach block 7 directly from block 3 we'll have _20 = *argv_12(MEM_10) = _20 in the expression hash table and _20 = 0 in the const/copies table. The first statement in block #7 loads *argv_32.  Without the temporary propagation we'll lookup *argv_32(MEM_10) in the hash table which misses and we're unable to thread the subsequent conditional in block #7. With the temporary propagation instead of looking up *argv_32(MEM_10), we propagate argv_12 for argv32 and lookup *argv32(MEM_10) which hits with the LHS value _20 which we then lookup in const/copies getting the constant 0.   Thus we know *argv_32 will have the value 0 when block 7 is reached directly via block 3.  That in turn allows us to know that the conditional at the end of block #7 is threadable when reached via block #3. In this particular testcase we end up getting a failure because... drumroll.... the failure to thread 3->7->9 leaves an infeasible path in the CFG which in turn causes a bogus Wuninitialized warning. Instead of actually propagating the arguments into the statement, we could revamp the hashing bits so that they used the data from the const/copy tables.    That would avoid twiddling the IL.  Though I'm still not sure how the IL twiddling could be escaping at this point. jeff