From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by sourceware.org (Postfix) with ESMTPS id 33E533858416 for ; Fri, 22 Oct 2021 15:59:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 33E533858416 Received: by mail-pj1-x1033.google.com with SMTP id e5-20020a17090a804500b001a116ad95caso3398228pjw.2 for ; Fri, 22 Oct 2021 08:59:37 -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-language :content-transfer-encoding; bh=MO/aG49DjaSoOwZrlRDKEXB2EZU1tzDJ+UoMXhOocvI=; b=wUCRH5+9/7O+s2tjA3BvdzhNmwKxltIOsx65moPUajaTWrzhIU4omvCjVw5shGMphN QSg46Wpc8uNz5tMwDz9059w25QlOCVks1ra1kElew3pznFGH+P+ZX44RRufRjso65pMJ zFleAGR953EsEtJJL2S6cePOsSc2peaZbFK8PLRQuGuues93CSV08XHvvaZLuZIxJmPZ 0uIUdiHK71Ne9oZ590iUG8VXu8cLLRuaMdifT3E9w01s2P7HGcYfiCCem8Y/cXo/QLWm gPUhajFSBdootCb5xN2QNNc55/Yl7jPVtTju2thVv+OJWE3pQYapVrgYjyCjtooky2+H Cxbw== X-Gm-Message-State: AOAM530goRoTE3b8xB0FFhE/UkiC9R4y+EBn6I9HHmMdJYbuGdq+6Xxq gZTax/Z41Gu8iZMx9REPN6rH2XBYv+I= X-Google-Smtp-Source: ABdhPJySkVHHHjT2ODn8xiSv3F0fpHbce8Io1Sy2KVhSmayeT3nv67TuqEyLsrPHr76+DaPVdWRoDw== X-Received: by 2002:a17:902:e2c3:b0:140:f6f:3256 with SMTP id l3-20020a170902e2c300b001400f6f3256mr287377plc.88.1634918376131; Fri, 22 Oct 2021 08:59:36 -0700 (PDT) Received: from [192.168.0.41] (184-96-250-116.hlrn.qwest.net. [184.96.250.116]) by smtp.gmail.com with ESMTPSA id k13sm7088977pfu.177.2021.10.22.08.59.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 Oct 2021 08:59:35 -0700 (PDT) Subject: Re: [PATCH] Try to resolve paths in threader without looking further back. To: Aldy Hernandez Cc: Jeff Law , GCC patches , Martin Sebor References: <20211020102816.656714-1-aldyh@redhat.com> <555af8e5-d068-4bf3-23ef-1041f5f7259c@gmail.com> From: Martin Sebor Message-ID: Date: Fri, 22 Oct 2021 09:59:30 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 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, WEIRD_PORT 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: Fri, 22 Oct 2021 15:59:39 -0000 On 10/22/21 9:18 AM, Aldy Hernandez wrote: > On Fri, Oct 22, 2021 at 4:27 PM Martin Sebor wrote: >> >> On 10/22/21 5:22 AM, Aldy Hernandez wrote: >>> On Thu, Oct 21, 2021 at 4:51 PM Martin Sebor wrote: >>> >>>> I'd like to see gimple-ssa-array-bounds invoked from the access >>>> pass too (instead of from VRP), and eventually -Wrestrict as well. >>> >>> You can do that right now. The pass has been converted to the new API >>> and it would just require calling it with a ranger instead of the >>> vr_values from VRP: >>> >>> array_bounds_checker array_checker (fun, &vrp_vr_values); >>> array_checker.check (); >>> >>> That is, move it where you want and pass it a fresh new gimple_ranger. >>> If there are any regressions, we'd be glad to look at them. >> >> I appreciate that and I'm not worried about regressions due to >> ranger code. >> >> It's not so simple as it seems because of the optimizer >> dependencies I mentioned. -Warray-bounds runs before vectorization >> and the access pass after it. Moving it into the access pass will >> mean dealing with the fallout: either accepting regressions in >> the quality of warnings (bad locations due to vectorization >> merging distinct stores into one) or running the access pass at >> a different point in the pipeline, and facing regressions in >> the other warnings due to that. Running it twice, once earlier >> for -Warray-bounds and then again later for -Wstringop-overflow >> etc, would be less than optimal because they all do the same >> thing (compute object sizes and offsets) and should be able to >> share the same data (the pointer query cache). So the ideal >> solution is to find a middle ground where all these warnings >> can run from the same pass with optimal results. >> >> -Warray-bounds might also need to be adjusted for -O0 to avoid >> warning on unreachable code, although, surprisingly, that hasn't >> been an issue for the other warnings now enabled at -O0. >> >> All this will take some time, which I'm out of for this stage 1. >> >>> >>>> I'm not sure about the strlen/sprintf warnings; those might need >>>> to stay where they are because they run as part of the optimizers >>>> there. >>>> >>>> (By the way, I don't see range info in the access pass at -O0. >>>> Should I?) >>> >>> I assume you mean you don't see anything in the dump files. >> >> I mean that I don't get accurate range info from the ranger >> instance in any function. I'd like the example below to trigger >> a warning even at -O0 but it doesn't because n's range is >> [0, UINT_MAX] instead of [7, UINT_MAX]: >> >> char a[4]; >> >> void f (unsigned n) >> { >> if (n < 7) >> n = 7; >> __builtin_memset (a, 0, n); >> } > > Breakpoint 5, get_size_range (query=0x0, bound= 0x7fffe9fefdc8 1>, range=0x7fffffffda10, > bndrng=0x7fffffffdc98) at > /home/aldyh/src/gcc/gcc/gimple-ssa-warn-access.cc:1196 > (gdb) p debug_ranger() > ;; Function f > > =========== BB 2 ============ > Imports: n_3(D) > Exports: n_3(D) > n_3(D) unsigned int VARYING > : > if (n_3(D) <= 6) > goto ; [INV] > else > goto ; [INV] > > 2->3 (T) n_3(D) : unsigned int [0, 6] > 2->4 (F) n_3(D) : unsigned int [7, +INF] > > =========== BB 3 ============ > : > n_4 = 7; > > n_4 : unsigned int [7, 7] > > =========== BB 4 ============ > : > # n_2 = PHI > _1 = (long unsigned int) n_2; > __builtin_memset (&a, 0, _1); > return; > > _1 : long unsigned int [7, 4294967295] > n_2 : unsigned int [7, +INF] > Non-varying global ranges: > =========================: > _1 : long unsigned int [7, 4294967295] > n_2 : unsigned int [7, +INF] > n_4 : unsigned int [7, 7] > > From the above it looks like _1 at BB4 is [7, 4294967295]. Great! > You probably wan: > > range_of_expr (r, tree_for_ssa_1, gimple_for_the_memset_call) That's what the function does. But its caller doesn't have access to the Gimple statement so it passes in null instead. Presumably without it, range_of_expr() doesn't have enough context to know what BB I'm asking about. It does work without the statement at -O but then there's just one BB (the if statement becomes a MAX_EXPR) so there's just one range. > > BTW, debug_ranger() tells you everything ranger would know for the > given IL. It's meant as a debugging aid. You may want to look at > it's source to see how it calls the ranger. Thanks for the tip. I should do that. There's a paradigm shift from the old ways of working with ranges and the new way, and it will take a bit of adjusting to. I just haven't spent enough time working with Ranger to be there. But this exchange alone was already very helpful! Martin