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 52568385840F for ; Thu, 2 Dec 2021 14:27:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 52568385840F Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-418-o5O3wW6fMnmZDBLi5z4mQA-1; Thu, 02 Dec 2021 09:27:31 -0500 X-MC-Unique: o5O3wW6fMnmZDBLi5z4mQA-1 Received: by mail-qk1-f199.google.com with SMTP id bm9-20020a05620a198900b004629c6f44c4so37674139qkb.21 for ; Thu, 02 Dec 2021 06:27:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=NSMwnQsT3rlKM4DhEJa+Qn73xNEvMKwnQFIZweO9MMM=; b=4G5haVndaRCSL48OWCXWON2RaUCjR2f++1vu1pqO/OIdeTzFbWNvVz+KcfKuLrAWVt JgoKnmkvay2xeIzHquDxvdZCAX5QmjJiD7BUN+QA1WVRcoOpWQAD0be+670V600U0x7a ZUoJjF7ib40c6vzgLgwmGKkzfLI+1qU0kRth9e5d4h0Y5Ga7x9ktq/v7ugfvBLgUkFPm IfyTaQw4S+xQzt9zkm2SYCmftyu3JEAY/14CzehN1Z5kNM7SV2vud2ltbqn97MUQKQCD kwu+AWTkhlAOXSvgs6Zw3kC8EgUgzCuTFjp6HOrJhD/ZnjHMsaNvDfbzHVS4KtgICj5p PN8A== X-Gm-Message-State: AOAM531I4boZImPfZZZjuKmwuzNqk/6uTNI3Ooeyi+aP1AoGBXBy3J5J pB4cHe3CGzUy78nsJQKpL5dOOjf5Bw7oW1lcp44hDoi3VKotl+mLaFC9rH5NNNsqR4lGiRYBFUH HnSIuzrqvyckKZXFROA== X-Received: by 2002:ad4:5744:: with SMTP id q4mr12915203qvx.99.1638455250697; Thu, 02 Dec 2021 06:27:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJxHi7K+pyBxBdqy3xKLLJFdb9LQArN3Z57u96b18LjP3qSPLKqA+wYoBthWcDk+cBPYk3Xs5A== X-Received: by 2002:ad4:5744:: with SMTP id q4mr12915185qvx.99.1638455250487; Thu, 02 Dec 2021 06:27:30 -0800 (PST) Received: from [192.168.0.102] ([104.219.122.97]) by smtp.gmail.com with ESMTPSA id x16sm3541qkp.67.2021.12.02.06.27.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Dec 2021 06:27:30 -0800 (PST) Message-ID: <757fdb5a-027e-5d3a-91b3-c7a81b597c94@redhat.com> Date: Thu, 2 Dec 2021 09:27:28 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: [PATCH] Loop unswitching: support gswitch statements. To: =?UTF-8?Q?Martin_Li=c5=a1ka?= , Richard Biener Cc: GCC Patches , Aldy Hernandez References: <0db1d9e8-f097-e766-a9fa-1a98c47b8115@suse.cz> <3a07ef98-d05f-dc07-2e36-a2b4ffd52936@suse.cz> <7bcc368c-3f26-4503-aec1-a3d6378e33ec@suse.cz> <561a3ffd-8973-d771-418f-76c484085cc5@suse.cz> <20265d97-6350-c234-695d-bc18e2e617b4@suse.cz> <1169b649-e3e2-36c9-f964-0b0ecd2530fa@suse.cz> <33509887-dfa3-6bb0-6fbe-cec8873f651f@suse.cz> <1423649f-7ef6-7408-36dc-4865f458b45e@redhat.com> <8f32d550-124c-9ed6-0ba1-a190a3f46ef0@suse.cz> From: Andrew MacLeod In-Reply-To: <8f32d550-124c-9ed6-0ba1-a190a3f46ef0@suse.cz> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-CA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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: Thu, 02 Dec 2021 14:27:38 -0000 On 12/2/21 06:45, Martin Liška wrote: > On 12/1/21 19:21, Andrew MacLeod wrote: >> On 12/1/21 09:48, Martin Liška wrote: >>> On 12/1/21 15:34, Richard Biener wrote: >>>> On Wed, Dec 1, 2021 at 3:25 PM Martin Liška wrote: >>>>> >>>>> On 12/1/21 15:19, Richard Biener wrote: >>>>>> which is compute the range of 'lhs' on edge_true into >>>>>> predicate->true_range, >>>>>> assign that same range to ->false_range and then invert it to get >>>>>> the >>>>>> range on the false_edge.  What I am saying is that for better >>>>>> precision >>>>>> you should do >>>>>> >>>>>>        ranger->range_on_edge (predicate->false_range, edge_false, >>>>>> lhs); >>>>>> >>>>>> rather than prematurely optimize this to the inversion of the >>>>>> true range >>>>>> since yes, ranger is CFG sensitive and only the_last_ predicate on a >>>>>> long CFG path is actually inverted. >>>>>> >>>>>> What am I missing? >>>>> >>>>> I might be misunderstood, but I think it's the problem defined here: >>>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584605.html >>>>> >>>>> where I used the ranger->range_on_edge on the false_edge. >>>> >>>> Ah, OK.  But then even the true_edge range is possibly wrong, no? >>> >>> You are of course correct, I've just proved that in debugger :// >>> >>>> Consider >>>> >>>>    for (;;) >>>>       { >>>>           if (a < 100) >>>>             if (a > 50)  // unswitch on this >>>>               /* .. */ >>>>           if (a < 120) >>>>               /* ... */ >>>>       } >>>> >>>> then you record [51, 99] for true_range of the a > 50 predicate and >>>> thus >>>> simplification will simplify the if (a < 120) check, no? >>> >>> Yep. >>> >>>> >>>> You can only record the range from the (CFG independent) a > 50 check, >>>> thus [51, +INF] but of course at simplification time you can also use >>>> the CFG context at each simplification location. >>> >>> @Andrew: How can I easily get irange based just on a stmt? Something >>> like fold_range >>> with int_range_max as the 3rd argument? >>> >> Sorry, I miss these things if I'm not directly CC'd a lot :-) >> >> So you just want to know the basic range the stmt generates without >> context?    Sure, what you say would be fine, but your want to >> initialize it to the type range: > > Yes, I want to know range of LHS in a gcond statement and the same for > cases in a gswitch statement. > >> >> int_range_max range (TREE_TYPE (name)); >> >> you can also simply trigger it using the current SSA_NAME_RANGE_INFO >> global  values query instead of the default current contextual one... >> which , if there isnt a global range, will automatically use the >> range of the type of the argument.. so maybe just try >> >> fold_range (r, stmt, get_global_range_query ()) > > Doing > >       predicate->true_range = int_range_max (TREE_TYPE (lhs)); >       fold_range (predicate->true_range, stmt, get_global_range_query > ()); >       predicate->true_range.debug(); > > gives me _Bool VARYING. wait, what  stmt are you asking for?  is this on something like: if (a < 120) ?  Then if it doesnt now anything about 'a', you would expect to get bool varying because the stmt is a true/false if you want to know the range of A on this, the instead, pick your edge, and ask ranger for the range of 'a' on the outgoing edge Now, I guess what you are looking for is the range of a without any context?  Then you'll want to access the GORI engine directly.. try ranger->gori().outgoing_edge_range_p (irange &r, edge e, tree name, *get_global_range_query ()); if you ask for 'a' on the true edge, it should give you [0,119] false edge should give you [120, +INF] same thing works for switches... pick and edge and it'll give you the range of NAME on that edge, without any contextual information. Anderw PS  if you DO want contextual,  skip the final argument and it'll go directly to what ranger knows at this time, without any additional lookups. Andrew