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 A8EA93858032 for ; Thu, 6 Jan 2022 16:42:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A8EA93858032 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-371-jUaxctMtMTeZTchVM9lVeQ-1; Thu, 06 Jan 2022 11:42:41 -0500 X-MC-Unique: jUaxctMtMTeZTchVM9lVeQ-1 Received: by mail-qk1-f199.google.com with SMTP id y21-20020a05620a09d500b004776ac05419so2200659qky.6 for ; Thu, 06 Jan 2022 08:42:41 -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=pjR9zx5bLnqY2b3X+YXgZzXnwx5KVVZ9JmSFWSPWPAM=; b=Qdj7rSJZt2tn8un6SizCkG2qFyJuY89BiUXQWdLzd/wrweQ0DRY4DgsNU1dHwjkdqa mHrGXo2Hn/6ND+fQ++Z1XB0I7fJyj1UYQGLoajPdlNPhYPNOChzOT/sMASN488wid2JY BH6EWL9N5L55IQ7VAEhujNWA3oQZ5TS3qYIjGmALDGc0E8Ow1Gd5pOkJIvAc4eyxjrXU e8wOUCS/wUt6hNoms6ZkKh0BZwFA8XDEbmO0iOhbcwDMsYnNtGqbZh4gofZCH69obox6 sWi0N83sBA1+PQxH8uszm7bcmV6Ctxb31MD804OXf4m3L1Hq6ykM/RCLdkIgmgx0ch7W m8DQ== X-Gm-Message-State: AOAM532xr8blB4M53BzDnPN3dvjB41TUUbq/txvlayb7cfRgwkKlvuuJ OvRmXrTCKYw6a7/0mLK/kOgmIBZ21k2YTqXrn6nT+RW5z7iR3mSZXPpdF8vFfsKLBOkN0hSiAJs xvx+PtsRApvkm00aQJA== X-Received: by 2002:a05:620a:1a05:: with SMTP id bk5mr821916qkb.537.1641487360749; Thu, 06 Jan 2022 08:42:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJxCKXUXMEhvAQnQY64SYYTTFpeER6XeMfhkxv5DfnUIr171wj1vnyW5r/fmbrAw57UgIjQ4zQ== X-Received: by 2002:a05:620a:1a05:: with SMTP id bk5mr821904qkb.537.1641487360557; Thu, 06 Jan 2022 08:42:40 -0800 (PST) Received: from ?IPV6:2607:fea8:a262:5f00:e36d:32da:80f:d4e1? ([2607:fea8:a262:5f00:e36d:32da:80f:d4e1]) by smtp.gmail.com with ESMTPSA id r185sm1590835qke.134.2022.01.06.08.42.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Jan 2022 08:42:39 -0800 (PST) Message-ID: Date: Thu, 6 Jan 2022 11:42:36 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: [PATCH] Loop unswitching: support gswitch statements. To: =?UTF-8?Q?Martin_Li=c5=a1ka?= , Richard Biener Cc: GCC Patches 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> <930e2424-a23d-9dc9-444a-991c829d98ad@redhat.com> <44776175-67a3-8bd8-b823-714b549c8f37@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=-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_H3, RCVD_IN_MSPIKE_WL, 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, 06 Jan 2022 16:42:45 -0000 On 1/6/22 11:35, Martin Liška wrote: > On 1/6/22 17:20, Andrew MacLeod wrote: >> So if you get a FALSE back, you cannot use any results because GORI >> is claiming that it cant figure something out... or there is nothing >> to figure out.   Most of rangers routines are implemented so that if >> they return FALSE, the result is meaningless. > > All right, then it's my bad, sorry for the noise. > >> >> >> what is IDX you are passing?  order_385? > > Yep. > > (gdb) p idx > $1 = > > >> >> As a side note, theres a typo in the testcase:  .. Im not sure how >> that affects things, but : > > Oh, yeah, that's typo :) > >> >>     defaut: >>              __builtin_unreachable (); >> >> >> default is misspelled...  maybe it thinks that some kind of runtime >> value?   I am surprised it even compiles.  maybe that is mucking up >> what GORI thiunks it can calculate? > > But it does not affect anything. The bailout happens due to: > > │      199    // Only process switches if it within the size limit. > │      200    if (EDGE_COUNT (e->src->succs) > (unsigned)m_max_edges) > │  >   201      return NULL; > > Cheers, > Martin > yeah its created by: gori_compute::gori_compute (int not_executable_flag)                       : outgoing (param_evrp_switch_limit), tracer ("GORI ") so as long as you change it to whatever you want before you create a ranger,  you should get whatever limit you want. anything above 255 may produce imprecise default values, if there are big holes in the switch because multi ranges only currently support up to 255 ranges.. so if there are more than 255 distinct subranges, it wont be exact. Andrew