From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id 7FDE33857831 for ; Thu, 2 Dec 2021 12:01:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7FDE33857831 Received: by mail-ed1-x531.google.com with SMTP id e3so115092207edu.4 for ; Thu, 02 Dec 2021 04:01:32 -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=fAIYAjPyTJd8O0vwlXzFEQ61usHbvLXlD6T+PiLnyv0=; b=WaVvxpK5/L6sIdOERhBBR02AakfoJwMuzXGYApbpCqTCo3GL5siXmf0dQrSZft0Y8R UsPuZof0jkbkliwHe6bOcKNetn2YR7aScSiZzdrN2hirjzA9NyPToiz1pE23rqLmDugH fpYN3/Bm4bHEh86sJEBT3xu1QKpgyNvWa7xBDYNPXB6+EwLGQbKn0ZNEdX0ou2voHRcF 2X9P03pDIutiFzysuSbvFD4cx7/hVZVl05qSgE8tmkyT6RGCwNTHpMCaSl2JK6P2JAI0 /W3zf19Lc6vOh4Dr98CVKeXsH1QNvwXBJ0TQ546Tp9N30FPQcJcL9KO9A2tUPtGKcMpS V/xA== X-Gm-Message-State: AOAM532t/LOTaRqmW9KrIf+8bZ6nhI8Uj3owcS681+O3DbWDp7cbah0g VisC0gDTchbqnd54dlBfRKQ7RpAsmvH0amMcFBE= X-Google-Smtp-Source: ABdhPJyp1wfT5f2bfggsI/D+SalXQGrWpRGBNAFE+HdFIVck1OExAiyjxW5e5TLFTXZLCi4/fomLeRnGewy6kH9rKfU= X-Received: by 2002:a05:6402:4389:: with SMTP id o9mr17448467edc.138.1638446491518; Thu, 02 Dec 2021 04:01:31 -0800 (PST) MIME-Version: 1.0 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> <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: <8f32d550-124c-9ed6-0ba1-a190a3f46ef0@suse.cz> From: Richard Biener Date: Thu, 2 Dec 2021 13:01:20 +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 12:01:34 -0000 On Thu, Dec 2, 2021 at 12:45 PM Martin Li=C5=A1ka wrote: > > 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 wro= te: > >>>> > >>>> On 12/1/21 15:19, Richard Biener wrote: > >>>>> which is compute the range of 'lhs' on edge_true into predicate->tr= ue_range, > >>>>> assign that same range to ->false_range and then invert it to get t= he > >>>>> range on the false_edge. What I am saying is that for better preci= sion > >>>>> you should do > >>>>> > >>>>> ranger->range_on_edge (predicate->false_range, edge_false, l= hs); > >>>>> > >>>>> rather than prematurely optimize this to the inversion of the true = range > >>>>> since yes, ranger is CFG sensitive and only the_last_ predicate on = a > >>>>> long CFG path is actually inverted. > >>>>> > >>>>> What am I missing? > >>>> > >>>> I might be misunderstood, but I think it's the problem defined here: > >>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584605.html > >>>> > >>>> 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 t= hus > >>> simplification will simplify the if (a < 120) check, no? > >> > >> Yep. > >> > >>> > >>> You can only record the range from the (CFG independent) a > 50 check= , > >>> thus [51, +INF] but of course at simplification time you can also use > >>> the CFG context at each simplification location. > >> > >> @Andrew: How can I easily get irange based just on a stmt? Something l= ike 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 con= text? Sure, what you say would be fine, but your want to initialize it t= o the type range: > > Yes, I want to know range of LHS in a gcond statement and the same for ca= ses in a gswitch statement. > > > > > int_range_max range (TREE_TYPE (name)); > > > > you can also simply trigger it using the current SSA_NAME_RANGE_INFO gl= obal values query instead of the default current contextual one... which ,= if there isnt a global range, will automatically use the range of the type= 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_query ()= ); > 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. 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. Richard. > > Martin > > > > > Andrew > > > > > > > > >