From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by sourceware.org (Postfix) with ESMTPS id 37F1C385840F for ; Thu, 2 Dec 2021 13:46:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 37F1C385840F Received: by mail-ed1-x529.google.com with SMTP id l25so116096068eda.11 for ; Thu, 02 Dec 2021 05:46:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OIS1D4fiGFEAxkojtcb/u+T3EKTRF1S56UMMM7+Q97s=; b=hDq4UZt3toqYNFJ2loO+LZIpyPh4ELd7dczey1UOEpvzAVOhK7I1HJMTW0bWjoe+FY adETrQM623Rvh3yzZv80CDKNh/PCpLPWG3rLhSKTwdgPzB6GGOoc9J5qT2jTa2bT6NLl rJhDbFFAcyZQZkW4ihII3TnMjyyvzMNvidW8RWWzyNe5BA9bjtOmH5YlqES4hhLC26/Q XWvrG1rWnzf1vRE/Zp0BWqQJlTNzWPfURp+PzPXvyC5r3jkOIO301sO9Zd5muP/yP67c xZLkjEDG5PDyDL3ZHwu8aYoBqQ9J/vCy6qv1jO2Dm/ji5Oyq8tY5GNl/Ga0pGkHch/5Q a0YQ== X-Gm-Message-State: AOAM530D04l6WvZHnuzluzbmGry4WMkAbyJ/rq/owUzTBTHKcFnqmt2b rrfhmkjRA4+4HvaJkbAYEFsRgiZ+KHzoGucbZ1w= X-Google-Smtp-Source: ABdhPJwtGtfoi1IKNk9LNPF3/qcMlNj4PwvrBSDYetFi5K07GE6hU2DCXz2/LEKpX+1PLSjSD7E/zoz/5IveO6ucT0Y= X-Received: by 2002:a17:906:a10c:: with SMTP id t12mr15493947ejy.429.1638452811009; Thu, 02 Dec 2021 05:46:51 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Richard Biener Date: Thu, 2 Dec 2021 14:46:39 +0100 Message-ID: Subject: Re: [PATCH] Loop unswitching: support gswitch statements. To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: Andrew MacLeod , GCC Patches , Aldy Hernandez Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 13:46:55 -0000 On Thu, Dec 2, 2021 at 2:10 PM Martin Li=C5=A1ka wrote: > > On 12/2/21 13:01, Richard Biener wrote: > > On Thu, Dec 2, 2021 at 12:45 PM Martin Li=C5=A1ka wrot= e: > >> > >> On 12/1/21 19:21, Andrew MacLeod wrote: > >>> On 12/1/21 09:48, Martin Li=C5=A1ka wrote: > >>>> On 12/1/21 15:34, Richard Biener wrote: > >>>>> On Wed, Dec 1, 2021 at 3:25 PM Martin Li=C5=A1ka w= rote: > >>>>>> > >>>>>> 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 pre= cision > >>>>>>> you should do > >>>>>>> > >>>>>>> ranger->range_on_edge (predicate->false_range, edge_false= , lhs); > >>>>>>> > >>>>>>> rather than prematurely optimize this to the inversion of the tru= e range > >>>>>>> since yes, ranger is CFG sensitive and only the_last_ predicate o= n a > >>>>>>> long CFG path is actually inverted. > >>>>>>> > >>>>>>> What am I missing? > >>>>>> > >>>>>> I might be misunderstood, but I think it's the problem defined her= e: > >>>>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584605.htm= l > >>>>>> > >>>>>> 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 che= ck, > >>>>> thus [51, +INF] but of course at simplification time you can also u= se > >>>>> 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 c= ontext? 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 ty= pe of the argument.. so maybe just try > >>> > >>> fold_range (r, stmt, get_global_range_query ()) > >> > >> Doing > >> > >> predicate->true_range =3D int_range_max (TREE_TYPE (lhs)); > >> fold_range (predicate->true_range, stmt, get_global_range_quer= y ()); > >> predicate->true_range.debug(); > >> > >> gives me _Bool VARYING. > > > > Likely because that gives a range for the bool result rather than > > a range for the LHS of a LHS op RHS on the true or false edge. > > Yes :) I guess Andrew can help us. some grepping and poking found be gimple_range_calc_op1 which should eventually do the trick (for constant gimple_cond_rhs at least). > > I would guess no stmt level API gives that. In previous VRP > > incarnation assert expr discovery would yield the asserts > > that hold for the LHS on the respective edge and from the asserts > > ranges could be determined. > > About the gswitch statements, I need similarly irange for a switch statem= ent > on an edge e. Well, you simply want a range (and condition to generate the if from) from a CASE_LABEL_EXPR. Given that's either a single integer constant or a RANGE_EXPR it should be easy to use some of the irange CTORs here. Richard. > Thanks for help, > Martin > > > > > Richard. > > > >> > >> Martin > >> > >>> > >>> Andrew > >>> > >>> > >>> > >>> > >> >