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.129.124]) by sourceware.org (Postfix) with ESMTPS id B7ABA3858D28 for ; Tue, 27 Jun 2023 17:54:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B7ABA3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687888483; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gt8y145IJBhlpNabD9oujInG/DWPsWHNKwqUZX1YcyA=; b=g52C6JgomdW7L5meq1eVtsYkmfso9DSGVqog+VNsxShFPCtWVaJ8WYjxXS87KuCPJFIYZc dQt9Wrj6Ps1n9dV1zOQg2ZX8nyudZnzSiHeu7i679VdG7V/t0ddDkRGewrpWvAf96I9got 1iqVKafLXJv16fTQEikDPRsQCw6Y34A= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-627--cU1RvCROSy-ehXS5Z8SWQ-1; Tue, 27 Jun 2023 13:54:41 -0400 X-MC-Unique: -cU1RvCROSy-ehXS5Z8SWQ-1 Received: by mail-qk1-f200.google.com with SMTP id af79cd13be357-76594ad37fcso294587185a.2 for ; Tue, 27 Jun 2023 10:54:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687888481; x=1690480481; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gt8y145IJBhlpNabD9oujInG/DWPsWHNKwqUZX1YcyA=; b=ParJgbE3tCyboGq3tIlCiCRHjRYFk/39JLn4Zgj6ksSVkPVgik1NOuMuFjFAN6NrjJ NqcCDYLCwzWEt7LMbrg8zGIsslNU6tpSoiYEEcNG+NHnm04ViHp1YNk+a4dJpdNpBy6Q 7cX7zvpuz3olW1RsuaFhUYcy+8YDbvJjuINKCBoRjFRU2CRjPEy4/UwiTjR4358nbc5U iPmN5+IKmSdOTofxkJnktcFWy1UGC0j5AxhM1Ih3h3KkErduCxRZfve0Iu/7MaR1V1xE ibUwGgjGJ3UkJ0r0XWJIswvAOPbr6ZYrLXEnktF1Zp36biZmdoZHZKuXYROUfSvUZlwm fmNQ== X-Gm-Message-State: AC+VfDymef+OBxwMtG4KNExmCzIi1Iz4ObPDxhMEzzrn43T2JsFzxjF+ E/Y2eq3/G/J1prXLZAioZhTg4jsS4tDhGCWCCyfkcvES6+2PqAXLWwlTYiOewCpZ8jmj0D9uoeq gFCFK4sOUl9yh1iOPJw== X-Received: by 2002:a05:620a:4043:b0:75e:2a27:253e with SMTP id i3-20020a05620a404300b0075e2a27253emr45417114qko.38.1687888481438; Tue, 27 Jun 2023 10:54:41 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4us6MlXYtDtts3ZZoi2nXCtqCiHjNDqDNMjgaJr19z3TAxoNmMXGfPU0BXo0DVmg3oXFFwWA== X-Received: by 2002:a05:620a:4043:b0:75e:2a27:253e with SMTP id i3-20020a05620a404300b0075e2a27253emr45417097qko.38.1687888481134; Tue, 27 Jun 2023 10:54:41 -0700 (PDT) Received: from ?IPV6:2607:fea8:51df:4200::ca58? ([2607:fea8:51df:4200::ca58]) by smtp.gmail.com with ESMTPSA id o2-20020a05620a110200b0075b13a89c30sm4195292qkk.3.2023.06.27.10.54.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jun 2023 10:54:40 -0700 (PDT) Message-ID: Date: Tue, 27 Jun 2023 13:54:39 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: Enable ranger for ipa-prop To: Jan Hubicka Cc: aldyh@redhat.com, mjambor@suse.cz, gcc-patches@gcc.gnu.org, jwakely@redhat.com References: <4d2f5bc2-c4ff-7576-cb82-b6c8a1a1da5f@redhat.com> From: Andrew MacLeod In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 6/27/23 12:24, Jan Hubicka wrote: >> On 6/27/23 09:19, Jan Hubicka wrote: >>> Hi, >>> as shown in the testcase (which would eventually be useful for >>> optimizing std::vector's push_back), ipa-prop can use context dependent ranger >>> queries for better value range info. >>> >>> Bootstrapped/regtested x86_64-linux, OK? >> Quick question. >> >> When you call enable_ranger(), its gives you a ranger back, but it also sets >> the range query for the specified context to that same instance.  So from >> that point forward  all existing calls to get_range_query(fun) will now use >> the context ranger >> >> enable_ranger (struct function *fun, bool use_imm_uses) >> <...> >>   gcc_checking_assert (!fun->x_range_query); >>   r = new gimple_ranger (use_imm_uses); >>   fun->x_range_query = r; >>   return r; >> >> So you probably dont have to pass a ranger around?  or is that ranger you >> are passing for a different context? > I don't need passing ranger around - I just did not know that. I tought > the default one is the context insensitive one, I will simplify the > patch. I need to look more into how ranger works. > > No need. Its magic! Andrew PS. well, we tried to provide an interface to make it as seamless as possible with the whole range-query thing. 10,000 foot view: The range_query object (value-range.h) replaces the old SSA_NAME_RANGE_INFO macros.  It adds the ability to provide an optional context in the form of a stmt or edge to any query.  If no context is provided, it simply provides the global value. There are basically 3 queries:   virtual bool range_of_expr (vrange &r, tree expr, gimple * = NULL) ;   virtual bool range_on_edge (vrange &r, edge, tree expr);   virtual bool range_of_stmt (vrange &r, gimple *, tree name = NULL); - range_of_stmt evaluates the DEF of the stmt, but can also evaluate things like  "if (x < y)" that have an implicit boolean LHS.  If NAME is provided, it needs to match the DEF. Thats mostly flexibility for dealing with something like multiple defs, you can specify which def. - range_on_edge provides the range of an ssa-name as it would be valued on a specific edge. - range_of_expr is used to ask for the range of any ssa_name or tree expression as it occurs on entry to a specific stmt. Normally we use this to ask for the range of an ssa-name as its used on a stmt,  but it can evaluate expression trees as well. These requests are not limited to names which occur on a stmt.. we can recompute values by asking for the range of value as they occur at other locations in the IL.  ie x_2 = b_3 + 5 <...> if (b_3 > 7)    blah (x_2) When we ask for the range of x_2 at the call to blah, ranger actually recomputes x_2 = b_3 + 5 at the call site by asking for the range of b_3 on the outgoing edge leading to the block with the call to blah, and thus uses b_3 == [8, +INF] to re-evaluate x_2 Internally, ranger uses the exact same API to evaluate everything that external clients use. The default query object is global_range_query, which ignores any location (stmt or edge) information provided, and simply returns the global value. This amounts to an identical result as the old SSA_NAME_RANGE_INFO request, and when get_range_query () is called, this is the default range_query that is provided. When a pass calls enable_ranger(), the default query is changed to this new instance (which supports context information), and any further calls to get_range_query() will now invoke ranger instead of the global_range_query.  It uses its on-demand support to go and answer the range question by looking at only what it needs to in order to answer the question.  This is the exact same ranger code base that all the VRP passes use, so you get almost the same level of power to answer questions.  There are just a couple of little things that VRP enables because it does a DOM walk, but they are fairly minor for most cases. if you use the range_query API, and do not provide a stmt or an edge, then we can't provide contextual range information, and you'll go back to getting just global information again. I think Aldy has converted everything to the new range_query API...  which means any pass that could benefit from contextual range information , in theory, only needs to enable_ranger() and provide a context stmt or edge on the range query call. Just remember to disable it when done :-) Andrew