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 B6DB23858408 for ; Thu, 6 Jan 2022 16:32:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B6DB23858408 Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-472-9rr8LBhBNGWDJTUF8IOjqQ-1; Thu, 06 Jan 2022 11:32:31 -0500 X-MC-Unique: 9rr8LBhBNGWDJTUF8IOjqQ-1 Received: by mail-qv1-f71.google.com with SMTP id 13-20020a0562140d0d00b00411590233e8so2532663qvh.15 for ; Thu, 06 Jan 2022 08:32: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=HlAeD7Bbf5W90nDSfTqACbD4s+wjVJ4DMYSUbCojfbM=; b=xd7bmT7EtSvKHq8VFi+k4lY0GaStG3BtDvH8oaJVRqg/XAtRH1dkT7CUvwV+zl6399 WzgFDfCTtwjDf9bN+MQvPDJEVzDCrK27evAmrDkPc0L1Qff3fjYHg7O/TTHUTtOmVo3I wmKcMSbSP7UvmZ7QSZjiOO4CtoSssDmxBxcNhMYN+osmGLGaMDdkoF3DaYwOV4FUK3Lt sLd8EIifye1c7dMiWwgNEMWPJhx9dyRCZhmr/viFV012F6HQsIgNH/hn5KY7Qv3p2sk4 mY2HHTu/F2H5/97hKt88wbQLsWV4u+t64gpFppijjlKrLWUm4xOa+6OZyd6wBtS4AAo0 6H6w== X-Gm-Message-State: AOAM532LWDUevw4tX402KCwjPwr9/YRCIdMlKGjd0y7V3kCDOw6+Wg/O yTspDNlPheHotfzyS6+yx6k4I78XIC1Uq/XxRPoX3Sp0gJV6ZaCd5EaIc0TWcFpws0wUZHiMFnE pZ8/U/pAaLfyFz1pE/A== X-Received: by 2002:a05:622a:40a:: with SMTP id n10mr3535320qtx.210.1641486751256; Thu, 06 Jan 2022 08:32:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJz33FFPEAO9nv4YVyrAmkL3C1P8GRpwDnNndlSSOvvwuvKyuJxtKBtWr0Zv+0hIB0IVcU1yzQ== X-Received: by 2002:a05:622a:40a:: with SMTP id n10mr3535292qtx.210.1641486750970; Thu, 06 Jan 2022 08:32:30 -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 s1sm1769156qtq.47.2022.01.06.08.32.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Jan 2022 08:32:30 -0800 (PST) Message-ID: <6d458c11-0d99-3a00-884c-5e2042689806@redhat.com> Date: Thu, 6 Jan 2022 11:32:29 -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> 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:32:43 -0000 On 1/6/22 11:02, Martin Liška wrote: > On 1/6/22 16:11, Andrew MacLeod wrote: >> On 1/5/22 07:34, Richard Biener wrote: >>> On Thu, Dec 9, 2021 at 2:02 PM Martin Liška wrote: >>>> On 11/30/21 12:17, Richard Biener wrote: >>>> >>> +                 unswitch_predicate *predicate >>> +                   = new unswitch_predicate (expr, idx, edge_index); >>> +                 ranger->gori ().outgoing_edge_range_p >>> (predicate->true_range, e, >>> +                                                        idx, >>> *get_global_range_query ()); >>> +                 /* Huge switches are not supported by Ranger.  */ >>> +                 if (predicate->true_range.undefined_p ()) >>> >>> I hope ranger will set the range to varying_p () in that case, not >>> undefined?  But even >>> then, is that a reason for punting?  I guess we fail to prune cases in >>> that case but >>> the cost modeling should then account for those and thus we are at >>> least consistent? >> >> huge switches not supported?  I don't know what you mean, either that >> or I forget :-)  If there are more edges than multi-ranges support, >> then things will start getting merged because they cant be >> represented.. and the default case may then also contain some values >> that also have cases..  but all inconsistencies will move towards >> varying.. not undefined. >> >> Andrew >> oh oh oh.   EVRp was spending too much time in very large switches, so we added a param to say "don't look at switches too big"   You are probably tripping over that -param=evrp-switch-limit= Common Joined UInteger Var(param_evrp_switch_limit) Init(50) Optimization Param Maximum number of outgoing edges in a switch before EVRP will not process it. and in GORI we check:       // Do not process switches if they are too large.       if (EDGE_COUNT (bb->succs) > (unsigned)param_evrp_switch_limit)         return; so maybe you want to temporarily override param_evrp_switch_limit to some big number for your purposes...  just set it back when you are done :-) Andrew