From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id 549F53856091 for ; Tue, 2 Aug 2022 12:15:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 549F53856091 Received: by mail-ed1-x52d.google.com with SMTP id z22so17355444edd.6 for ; Tue, 02 Aug 2022 05:15:04 -0700 (PDT) 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; bh=lB7vDrJ6xBq/FmplgW72HLlnoEoPTNCxkHTuu8nHPnw=; b=3OpdEUgq16vgLDQepi1CQaSdpVA4+ZmY70k2qdznP0MKRImYGmNtO03m99DJVBRoWW tGczLxm2Kk/6dLvAT4fTQbmor9t80FkFo698YaruRxxjXPviZ4styNxzKjQS6iQdwkvW Nfv9U6rKZt/yX1bTn/mI62499UV87BTyDnQjsniiyDBwem9Hl3GIm+9UKNlC/ICr/x1a tbP84Wm3ByQtrAKmlsmmCGqLgAtyhBH/CEnNJS7+ipSz9ZkZivK5s/kHBZD/UnWdv3H2 BsTwPdPPhEdMrJgCpZL7aVMM2mjBNAvyLcoAwmnkwkCubc93TUXu4le+BTRMh/boxCxH 4uYQ== X-Gm-Message-State: ACgBeo1lbX0QwoARpU9ylVb63lBLpJpPbWDO7GnQ+UHtVDEntwzwtSCJ zto+xMr9xmK78HCAnGSXsXnwJT5ARQermvFrO5M= X-Google-Smtp-Source: AA6agR7bcBQoJqEpKuvoAyUCs/Lp4AYPoylxe7dPL12yN5esS9L5HeUdC4LA4c08SaiT3tPfjwptMRjFrb+Eu7yDsTo= X-Received: by 2002:aa7:db85:0:b0:43d:609b:2592 with SMTP id u5-20020aa7db85000000b0043d609b2592mr14181046edt.147.1659442503081; Tue, 02 Aug 2022 05:15:03 -0700 (PDT) MIME-Version: 1.0 References: <20220801061540.229684-1-aldyh@redhat.com> In-Reply-To: From: Richard Biener Date: Tue, 2 Aug 2022 14:14:50 +0200 Message-ID: Subject: Re: [COMMITTED] Make irange dependency explicit for range_of_ssa_name_with_loop_info. To: Aldy Hernandez Cc: "MacLeod, Andrew" , GCC patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Tue, 02 Aug 2022 12:15:05 -0000 On Tue, Aug 2, 2022 at 2:11 PM Aldy Hernandez wrote: > > On Tue, Aug 2, 2022 at 2:07 PM Richard Biener > wrote: > > > > On Tue, Aug 2, 2022 at 1:41 PM Aldy Hernandez wrote: > > > > > > On Tue, Aug 2, 2022 at 9:19 AM Richard Biener > > > wrote: > > > > > > > > On Mon, Aug 1, 2022 at 8:17 AM Aldy Hernandez via Gcc-patches > > > > wrote: > > > > > > > > > > Even though ranger is type agnostic, SCEV seems to only work with > > > > > integers. This patch removes some FIXME notes making it explicit that > > > > > bounds_of_var_in_loop only works with iranges. > > > > > > > > SCEV also handles floats, where do you see this failing? Yes, support is > > > > somewhat limited, but still. > > > > > > Oh, it does? We could convert range_of_ssa_name_with_loop_info to > > > the type agnostic vrange if so... (see attached untested patch). > > > > > > I'm looking at the testcase for 24021 with the attached patch, and > > > bounds_of_var_in_loop() is returning false because SCEV couldn't > > > figure out the direction of the loop: > > > > > > dir = scev_direction (chrec); > > > if (/* Do not adjust ranges if we do not know whether the iv increases > > > or decreases, ... */ > > > dir == EV_DIR_UNKNOWN > > > /* ... or if it may wrap. */ > > > || scev_probably_wraps_p (NULL_TREE, init, step, stmt, > > > get_chrec_loop (chrec), true)) > > > return false; > > > > > > The chrec in question is rather simple... a loop increasing by 0.01: > > > > > > (gdb) p debug(chrec) > > > {1.00000000000000002081668171172168513294309377670288085938e-2, +, > > > 1.00000001490116119384765625e-1}_1 > > > > Well, yeah - I meant it "supports" floats in that it can analyze the CHRECs (you > > quote that) and it shouldn't ICE anywhere. But of course some things may > > return "I don't know" when not implemented. Like scev_direction which has > > > > step = CHREC_RIGHT (chrec); > > if (TREE_CODE (step) != INTEGER_CST) > > return EV_DIR_UNKNOWN; > > > > if (tree_int_cst_sign_bit (step)) > > return EV_DIR_DECREASES; > > else > > return EV_DIR_GROWS; > > > > so it lacks support for REAL_CST step. Would be interesting to see what happens > > with a loop with -0.0 "increment" and honoring signed zeros. That said, > > inspecting the sign bit of a REAL_CST and handling zero (of any sign) as > > EV_DIR_UNKNOWN would probably work. > > > > > I also see that bounds_of_var_in_loop() calls niter's > > > max_loop_iterations(), which if I understand things correctly, bails > > > at several points if the step is not integral. > > > > Yes, a lot of code is "simplified" by not considering FP IVs. But it "works" > > in terms of "it doesn't ICE" ;) > > That's a very generous interpretation of "works" :-). ;) > In that case I will make our code type agnostic, with the previously > attached patch (after testing). Then whenever SCEV and > bounds_of_var_in_loop (which also seems to be integer centric) support > floats, everything will just work. Sounds good. Richard. > Thanks. > Aldy >