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 7FE743858032 for ; Thu, 6 Jan 2022 16:20:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7FE743858032 Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-152-antEyBEBNdaqruKrdQUUxA-1; Thu, 06 Jan 2022 11:20:27 -0500 X-MC-Unique: antEyBEBNdaqruKrdQUUxA-1 Received: by mail-qt1-f200.google.com with SMTP id s6-20020a05622a018600b002b2d93b9c73so2352466qtw.9 for ; Thu, 06 Jan 2022 08:20:27 -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; bh=JfgarEPBsrhTPE6MEctCYG2Ck5M1pXNsDvFCrj/OlyQ=; b=nZy+a/65see3HWZxzB9Re765yozSSEukFJk37g/zIou8msyUZVXjaqAYmw6YBcsd3y 6XcjHRCIS4sb1urcvidnv4mo3PdaRBwh5BepifP19m0B5tBurbiqKXH9JioQZP7+GxMw Gb/1SrklqufGqsASMC3SeihBIIDWRK7cy/ieP1sptCHJOcRyo9LNVa4WU+FOtdavfpYN IdvXXTgpBo+o63llTYQrXe1+RCKRCbCXAVCgZrJscMa+/lw1EZmjtClj7gV9J3ru+H20 MrcIioTQUEXK9tLYGKWOp26+RSeQTN2JfGbN6l/BVIXtPPiHsFcBNUUg0F1DJs1IMXVv 52pw== X-Gm-Message-State: AOAM531ct/gtaK1nyLQIWVRSba3erFssSb8d2thxDcTpwGV3YGFPY/R2 08urnJ8sv2j75OH1ixTJNV1NQYH5PRYJdTDef7cnnGwIRe9D71OZO36xOpIE29FdGrDO4yCtZqm m/JUfNUdjeg3ilCZXIg== X-Received: by 2002:ac8:5f47:: with SMTP id y7mr52659972qta.342.1641486025333; Thu, 06 Jan 2022 08:20:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJxnd4rabUMtjkGc682zq8OcMzQa70MTI9Rp86m4FlJW7P1BCVFZdNyZOv+wIxXPdlDgdOLe1Q== X-Received: by 2002:ac8:5f47:: with SMTP id y7mr52659857qta.342.1641486023636; Thu, 06 Jan 2022 08:20:23 -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 x1sm1776504qtj.9.2022.01.06.08.20.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Jan 2022 08:20:22 -0800 (PST) Message-ID: <44776175-67a3-8bd8-b823-714b549c8f37@redhat.com> Date: Thu, 6 Jan 2022 11:20:21 -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 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, HTML_MESSAGE, 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 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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:20:38 -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 >> > > Hello. > > If you consider the attached test-case, then I get for: > > (gdb) p debug_bb(e->src) > [local count: 955630225]: > # i_489 = PHI > # tmp_490 = PHI > _1329 = (long unsigned int) i_489; > _1330 = _1329 * 8; > switch (order_385(D)) [1.08%], case 0: [1.08%], > case 1: [1.08%], case 2: [1.08%], case 3: [1.08%], case > 4: [1.08%], case 5: [1.08%], case 6: [1.08%], case 7: > [1.08%], case 8: [1.08%], case 9: [1.08%], case 10: > [1.08%], case 11: [1.08%], case 12: [1.08%], case > 13: [1.08%], case 14: [1.08%], case 15: [1.08%], > case 16: [1.08%], case 17: [1.08%], case 18: > [1.08%], case 19: [1.08%], case 20: [1.08%], case 21: > [1.08%], case 22: [1.08%], case 23: [1.08%], case > 24: [1.08%], case 25: [1.08%], case 26: [1.08%], > case 27: [1.08%], case 28: [1.08%], case 29: > [1.08%], case 30: [1.08%], case 31: [1.08%], case 32: > [1.08%], case 33: [1.08%], case 34: [1.08%], case > 35: [1.08%], case 36: [1.08%], case 37: [1.08%], > case 38: [1.08%], case 39: [1.08%], case 40: > [1.08%], case 41: [1.08%], case 42: [1.08%], case 43: > [1.08%], case 44: [1.08%], case 45: [1.08%], case > 46: [1.08%], case 47: [1.08%], case 48: [1.08%], > case 49: [1.08%], case 50: [1.08%], case 51: > [1.08%], case 52: [1.08%], case 53: [1.08%], case 54: > [1.08%], case 55: [1.08%], case 56: [1.08%], case > 57: [1.08%], case 58: [1.08%], case 59: [1.08%], > case 60: [1.08%], case 61: [1.08%], case 62: > [1.08%], case 63: [1.08%], case 64: [1.08%], case 65: > [1.08%], case 66: [1.08%], case 67: [1.08%], case > 68: [1.08%], case 69: [1.08%], case 70: [1.08%], > case 71: [1.08%], case 72: [1.08%], case 73: > [1.08%], case 74: [1.08%], case 75: [1.08%], case 76: > [1.08%], case 77: [1.08%], case 78: [1.08%], case > 79: [1.08%], case 80: [1.08%], case 81: [1.08%], > case 82: [1.08%], case 83: [1.08%], case 84: > [1.08%], case 85: [1.08%], case 86: [1.08%], case 87: > [1.08%], case 88: [1.08%], case 89: [1.08%], case > 90: [1.08%], case 91: [1.08%]> > > $7 = void > (gdb) p debug_bb(e->dest) > [local count: 10275591]: > : > _3 = a_386(D) + _1330; > _4 = *_3; > tmp_478 = _4 * 0.0; > goto ; [100.00%] > > │      480                    ranger->gori ().outgoing_edge_range_p > (predicate->true_range, e, > │ 481                                                           idx, > *get_global_range_query ()); > > Note the return value is false. But I think the comment is not precise: 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. what is IDX you are passing?  order_385? As a side note, theres a typo in the testcase:  .. Im not sure how that affects things, but : 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? > > │     1233  // Calculate a range on edge E and return it in R. Try to > evaluate a > │     1234  // range for NAME on this edge.  Return FALSE if this is > either not a > │     1235  // control edge or NAME is not defined by this edge. > > and > > (gdb) p predicate->true_range.debug() > UNDEFINED > > So is the behavior correct Andrew? > Thanks, > Martin >