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 E0FE73858D28 for ; Fri, 3 Dec 2021 14:09:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E0FE73858D28 Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-40-OaqD5nNFPK-_zCUKHHcKUw-1; Fri, 03 Dec 2021 09:09:42 -0500 X-MC-Unique: OaqD5nNFPK-_zCUKHHcKUw-1 Received: by mail-qt1-f198.google.com with SMTP id v17-20020a05622a131100b002aea167e24aso3665975qtk.5 for ; Fri, 03 Dec 2021 06:09:42 -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=DD48ii+buyK3qNwC+O3ldFII0PZQkjhQZ/kVQKNEDkc=; b=7KRxK+Ce/ll+LAu09klk5Mud9BEY+jPYtr/khhaKnowknM5JsDATpGuT9zGT5tAFeO gE1ePcrxUEP3tPGoDKVDhkmVKT2TGQJAdaSogXOMBfMiBewFnkV1TenUyxA6TcmQ9S// zUpyqQGnDCPoeE3Ka6P94VWb/izC4KkF6iNo09Jqr7/WZlaq2HAeGuYcvvYtewwFV6Hh qav/PzHfYn6R1PSACH8i08krcACLouymka3YcqC3G+6tbEzfDm+FHjC5MdluXIpyRRq6 ZzzP17aOIqULLe2t0Js5bkkDlMiKa8Jv5Cr7m/qGMe7qbIAErLJl8UMDFnnmSgx3AKqv icKw== X-Gm-Message-State: AOAM533e9+Z3ooay5t5dSfmraCe5R93fRQyDDVFBzMMSZlo1QQnEdFLM +DDNz3vDXcPDiZHLBGXX/PUK2BozR0W2O9qMcj+nGx1k/j41lTQg72X3nGUAGFovf3ind7ETsoL x5mlqLGVh01Rcou00pg== X-Received: by 2002:ac8:5742:: with SMTP id 2mr20692068qtx.554.1638540581530; Fri, 03 Dec 2021 06:09:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJyfe/0Gfq7S0Zb3ggr3nNJXz30pjii/YxP7umGa/0Mxr99ydKbAfYLi3k5Bv0tLbX/NRerqqg== X-Received: by 2002:ac8:5742:: with SMTP id 2mr20692033qtx.554.1638540581269; Fri, 03 Dec 2021 06:09:41 -0800 (PST) Received: from ?IPV6:2607:fea8:a262:5f00::6d7? ([2607:fea8:a262:5f00::6d7]) by smtp.gmail.com with ESMTPSA id u10sm2488319qtx.3.2021.12.03.06.09.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Dec 2021 06:09:40 -0800 (PST) Message-ID: <9cf19620-befb-314f-07a3-d18c3e613dcb@redhat.com> Date: Fri, 3 Dec 2021 09:09:39 -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: <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> <757fdb5a-027e-5d3a-91b3-c7a81b597c94@redhat.com> From: Andrew MacLeod In-Reply-To: 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=-4.7 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 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, 03 Dec 2021 14:09:46 -0000 On 12/2/21 11:02, Martin Liška wrote: > On 12/2/21 15:27, Andrew MacLeod wrote: >> ranger->gori().outgoing_edge_range_p (irange &r, edge e, tree name, >> *get_global_range_query ()); > > Thank you! It works for me! > > Martin > btw, this applies to names not  on the stmt as well.   The function returns TRUE if there is an outgoing range calculable, and false if not.  so: a = b + 20 if (a > 40)        <- returns TRUE for outgoing range of 'a' or 'b'     {        c = foo()        if (c > 60)   <- returns false for 'a' or 'b'            {                if (b < 100)   <- Also returns TRUE for 'a' or 'b' The final block, from the EVRP dump:     :     if (b_4(D) <= 99)       goto ; [INV]     else       goto ; [INV] 4->5  (T) b_4(D) :      unsigned int [21, 99] 4->5  (T) a_5 :         unsigned int [41, 119] 4->6  (F) b_4(D) :      unsigned int [100, 4294967275] 4->6  (F) a_5 :         unsigned int [120, +INF] Shows that it has a range for both 'a' and 'b'. Just to point out that you can use this query on any conditional edge, even if it isnt directly mentioned on the stmt.  so if you are keying of 'a', you could simply ask if outgoing_edge_range_p ( , a,...)  rather than parsing the condition to see if 'a' is on it.   if there is no chance that 'a' is affected by the block, is just returns false. When its called directly like this, it picks up no ranges from outside the basic block you are querying, except via that range query you provide. The listing shows the defaultwhic is whatever ranger knows.   So if you provided get_global_range_query, those ranges would instead be something like: 4->5  (T) b_4(D) :      unsigned int [0, 99] 4->5  (T) a_5 :         unsigned int [21, 119] 4->6  (F) b_4(D) :      unsigned int [100, +INF] 4->6  (F) a_5 :         unsigned int [0,20] [120, +INF-20 ] It may simplify things a little if you are unswitching on 'a', you can just ask each block with a condition whether 'a's range can be modified.... Andrew.