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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 6FC013896C25 for ; Tue, 25 May 2021 09:36:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6FC013896C25 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-1--dgAPWolMDesjuqnIZUQEQ-1; Tue, 25 May 2021 05:36:47 -0400 X-MC-Unique: -dgAPWolMDesjuqnIZUQEQ-1 Received: by mail-wm1-f71.google.com with SMTP id h129-20020a1c21870000b02901743c9f70b9so4586289wmh.6 for ; Tue, 25 May 2021 02:36:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=GFwSOFL4VIghx3/W0rSAMGTxGe11mU+LwttReNKXiOI=; b=IWua2oT0yxg/83hUeX+HTWcCqkq9pn7JnppTu7OpwFXll3OGAZZRiF7YG0Z91WvY5B 3hFJ3SJ98NBViQVW2Cg9EYq3dgCnjfFp/q2NUuJHNoFzpe6/aH+sdxMjV4mO4ao/XJcA pDIJJ2rbqHJEJD0CCnChaWcZkf7wkbNKVqxnsykv1kUkdNb0psA1EBlT+DET6hUie5Z0 8b4BXvqOwcyD/1QwNnZlTlps5aBv0tyPNfaM2SLcyYtOt0xQ+kqJoxTq++v/IyiqXEVb d/vXL3lqHE+6NhrhWdzPAGC89F4n0BJ5lqnuW7w/7cxtuAx703ekCTOYag54SDPHZN7F YUdw== X-Gm-Message-State: AOAM531Fhlqigc56pWUUvM1KOwL5+7Tp7+YGULacCd+xvJEICDF/ayzT LW4cQZGLv318i6OI822v0WpZW4cjaWtsajpyEVTxiqnj47DE0IYkJ98vlF9yvi0kCdvHbOV30JZ UWcS8GaLvobhRdz3hTA== X-Received: by 2002:a05:600c:4fd6:: with SMTP id o22mr22968779wmq.83.1621935406034; Tue, 25 May 2021 02:36:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxEDCw3aKFZNkPzH+ZNYdMs7t4zh2iIUuzSXemi4WpIKTDhNZaS8lAdUrC8ivdJdigR0NPgSw== X-Received: by 2002:a05:600c:4fd6:: with SMTP id o22mr22968759wmq.83.1621935405795; Tue, 25 May 2021 02:36:45 -0700 (PDT) Received: from abulafia.quesejoda.com ([95.169.237.215]) by smtp.gmail.com with ESMTPSA id y20sm2367948wmi.0.2021.05.25.02.36.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 May 2021 02:36:45 -0700 (PDT) Subject: Re: [PATCH 1/5] Common API for accessing global and on-demand ranges. To: Richard Biener Cc: GCC patches , Andrew MacLeod , Martin Sebor References: <20210521113954.1148075-1-aldyh@redhat.com> <71bc0536-573b-a389-89f5-f13f5763d3df@redhat.com> From: Aldy Hernandez Message-ID: <203d1cae-2844-7f58-a334-ce0e96cf52a2@redhat.com> Date: Tue, 25 May 2021 11:36:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 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: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Tue, 25 May 2021 09:36:50 -0000 On 5/25/21 10:57 AM, Richard Biener wrote: > On Mon, May 24, 2021 at 6:44 PM Aldy Hernandez via Gcc-patches > wrote: >> >> >> >> On 5/21/21 1:39 PM, Aldy Hernandez wrote: >>> This patch provides a generic API for accessing global ranges. It is >>> meant to replace get_range_info() and get_ptr_nonnull() with one >>> common interface. It uses the same API as the ranger (class >>> range_query), so there will now be one API for accessing local and >>> global ranges alike. >>> >>> Follow-up patches will convert all users of get_range_info and >>> get_ptr_nonnull to this API. >>> >>> For get_range_info, instead of: >>> >>> if (!POINTER_TYPE_P (TREE_TYPE (name)) && SSA_NAME_RANGE_INFO (name)) >>> get_range_info (name, vr); >>> >>> You can now do: >>> >>> RANGE_QUERY (cfun)->range_of_expr (vr, name, [stmt]); >> >> BTW, we're not wed to the idea of putting the current range object in >> cfun. The important thing is that the API is consistent across, not >> where it lives. > > If the range object is specific for a function (and thus cannot handle > multiple functions in IPA mode) then struct function looks like the correct > place. Accessing that unconditionally via 'cfun' sounds bad though because > that disallows use from IPA passes. The default range object can either be the "global_ranges" object (get_range_info / get_ptr_nonnull wrapper) or a ranger. So, the former is global in nature and not tied to any function, and the latter is tied to the gimple IL in a function. What we want is a mechanism from which a pass can query the range of an SSA (or expression) at a statement or edge, etc agnostically. If a ranger is activated, use that, otherwise use the global information. For convenience we wanted a mechanism in which we didn't have to pass an object between functions in a pass (be it a ranger or a struct function). Back when I tried to convert some passes to a ranger, it was a pain to pass a ranger object around, and having to pass struct function would be similarly painful. ISTM, that most converted passes in this patchset already use cfun throughout. For that matter, even the two IPA ones (ipa-fnsummary and ipa-prop) use cfun throughout (by first calling push_cfun (node->decl)). How about I use fun if easily accessible in a pass, otherwise cfun? I'm trying to avoid having to pass around a struct function in passes that require surgery to do so (especially when they're already using cfun). Basically, we want minimal changes to clients for ease of use. Aldy