From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id A3AD13858D28 for ; Sat, 23 Oct 2021 08:31:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A3AD13858D28 Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-270-H1kR3vo3NqyY6FpPulpsMQ-1; Sat, 23 Oct 2021 04:31:55 -0400 X-MC-Unique: H1kR3vo3NqyY6FpPulpsMQ-1 Received: by mail-wm1-f71.google.com with SMTP id 128-20020a1c0486000000b0030dcd45476aso1929948wme.0 for ; Sat, 23 Oct 2021 01:31:55 -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=ax+hO3iL/2kYl4C+8rReudwfj88j1l9pfLWPFzPsp2A=; b=p/4/i5fnjdcVI4ddPKTOa6jENk7bgrSHsDN6m4k4pBZuAG4rQp1MSjLLLZgUF8hNJg 3XGTb2IoE6to3PEQ0tlr+uP6MmJFOY3FEEWaKgFUnCaF8JktnbUTkjLAOs5iRYWtAd25 UkCOUgPQ7mIsMyQ5+HURSZsiag1CagXa1IymI85Tmo6MH5sXGLN3wuFVcKlC4X5ZPTfG qY46G6PzpANhwstLOJrwnQP+cUGaGUu6NhvdroqZn0AsqTv6knaULLP27Zjq4Wi+WOx8 XRwG8Y/J6aF2D8l9q0sFfaBuTWIfcDPpvW5TOD4AkD1dnRDKhWMiKzBwHonvPKWi91so 3q4g== X-Gm-Message-State: AOAM533qxVU9YKLaNpPEpv9ndIDv8DRRN4URTuaatdWouaRCPj0fEfH2 LEMIq7SXbwDAPUFawN+byzJV9YN2jDyGzEnAHixPatBMJdxq+R7+tl9/KZoBudoITFvwUVLnO1Z rfMlZhYHGfd9kphYstw== X-Received: by 2002:adf:d4c9:: with SMTP id w9mr550996wrk.372.1634977913840; Sat, 23 Oct 2021 01:31:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwBY5flW+S5VDDqJ7r0XvuCGCmVLauW0xGHSQ/5ZoiRliUmuAAgakqNiiPpadVdmbnqVhaurw== X-Received: by 2002:adf:d4c9:: with SMTP id w9mr550973wrk.372.1634977913624; Sat, 23 Oct 2021 01:31:53 -0700 (PDT) Received: from abulafia.quesejoda.com ([139.47.33.227]) by smtp.gmail.com with ESMTPSA id d8sm10648538wrv.80.2021.10.23.01.31.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 23 Oct 2021 01:31:53 -0700 (PDT) Subject: Re: [PATCH] Try to resolve paths in threader without looking further back. To: Martin Sebor Cc: Jeff Law , GCC patches , Martin Sebor , Andrew MacLeod References: <20211020102816.656714-1-aldyh@redhat.com> <555af8e5-d068-4bf3-23ef-1041f5f7259c@gmail.com> From: Aldy Hernandez Message-ID: <196d5dff-bf7b-4250-65aa-64cddfccd9d2@redhat.com> Date: Sat, 23 Oct 2021 10:31:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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: Sat, 23 Oct 2021 08:32:01 -0000 On 10/22/21 5:59 PM, Martin Sebor wrote: > 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: >>>>> (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 want: >> >>    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! You can query the ranger on any point in the IL. However, if you don't give it context, it'll just return the globally known range. In this case it'll be the global SSA range, which is unset because the usual setters haven't run at -O0 (evrp, VRP*). So yes, you need to pass it correct context. Yes, it's a paradigm shift. The evrp engine worked by pushing state as you did a dom walk, so you could ask for SSA ranges that were specific to the path sensitive point you were in the walk. The ranger is far more versatile, in which you can ask for a range on an edge, block, or statement, regardless of how you're iterating through the gimple. You can also use the ranger to indirectly tell you about reachability. For example, if you ask for the range of x_6 at a point in the IL and the answer comes out as UNDEFINED, that point is unreachable. That is, assuming x_6 is considered live at the query point. IIRC, if you ask for x_6 at a point not dominated by the definition of x_6, the ranger will also return UNDEFINED. The ranger API is designed to be minimal and simple: bool range_of_stmt (irange &r, gimple *, tree name = NULL); bool range_of_expr (irange &r, tree name, gimple * = NULL); bool range_on_edge (irange &r, edge e, tree name); void range_on_exit (irange &r, basic_block bb, tree name); Andrew keeps threatening he'll write up some articles this year on the ranger and its reusable components. *prod* :) Aldy