From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by sourceware.org (Postfix) with ESMTPS id 8AE3C3858416 for ; Fri, 22 Oct 2021 14:27:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8AE3C3858416 Received: by mail-pj1-x1036.google.com with SMTP id e5-20020a17090a804500b001a116ad95caso3201566pjw.2 for ; Fri, 22 Oct 2021 07:27:10 -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=BYwz+NuA7CxwifbhvCRQKAenXTu1zR6NzM+Wvv3RQTE=; b=Hi6Vz5Bxn0ap3cQKZvGhdkLiEaafqNADudHu4HN/kO7r0duUAuesMfDR5gMtNkGHms UvKfZZD4lASQkN0/wuFDxh1w/a4Yx4BspjyJBejKa4Z434Ejjgz6KTHPWUa/hnRtMRo2 OI1c/7884KSB5/4kjMYzz6BAkQ1H66pyMwhZHxlO1NAo6Pg5XMSNNyK2gYf6N39+0a6i tXN7MefoCa+OfFQOnsud/aUeJZnwg72uCjSkdgRd0j0xxEqNzJ/xw3qV8yZePzggn26e 0+Iz0jvI2svGZXKMxDt3MyYDyBoKxBEXd6oUco6vH/CjZeXO2HmISR1C4ae9yVhX/c22 I74A== X-Gm-Message-State: AOAM533cExDgoOj/Cm+QNYdG+SQcGanmeZfy2Tcew00muAbKUZLx4o9J 5OjP5PW9cudXYKBKKO84Bhk= X-Google-Smtp-Source: ABdhPJwPccoPiL9it8VgtWNJXv8wE6RKHBl1e8RxRRR7oIH+TfubIQVFm9wtERAVso8onqd+yNHj3w== X-Received: by 2002:a17:902:8ec4:b0:13f:a392:29d4 with SMTP id x4-20020a1709028ec400b0013fa39229d4mr319481plo.76.1634912829619; Fri, 22 Oct 2021 07:27:09 -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 s3sm11673363pfu.84.2021.10.22.07.27.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 Oct 2021 07:27:09 -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 08:27:03 -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 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 14:27:12 -0000 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); } > > None of the VRP passes (evrp included) run at -O0, so you wouldn't see > anything in the IL. You *may* be able to see some global ranges that > DOM's use of the evrp engine exported, but I'm not sure. > > You're going to have to instantiate a gimple_ranger and use it if you > want to have range info available, but that's not going to show up in > the IL, even after you use it, because it doesn't export global ranges > by default. What are you trying to do? The above. The expected warning runs in the access warning pass. It uses the per-function instance of the ranger but it gets back a range for the type. To see that put a breakpoint in get_size_range() in pointer-query.cc and compile the above with -O0. Martin