From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 1B6A13856DE2 for ; Tue, 2 Aug 2022 12:07:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1B6A13856DE2 Received: by mail-ej1-x634.google.com with SMTP id k26so9827244ejx.5 for ; Tue, 02 Aug 2022 05:07:00 -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=TR38RAsFzFgQY+suO8ncSJSvr/aE89cLjWaFIE4jYNA=; b=nAGST8liQwGo4x5k8FNu6CYVUl4O4NtKw3Abb4QGd3sITTtGYsIZNfWoQwemWt3ZSH hFcOhsdyZG7g0aEJ2QTGV/u82oSb7nLpEeEs6i9XhHZeNJ9g+NTEJdnaUZJcJw/IZtoB ZkM2Ns41tbkGx2NYhfl4wbI8sX6hjwPr3L5neN8vJfv4QQ9sMWXRZJL+KvOcHt5MZhea X9ZTN7jLMrtv/q+aS465AA8fr3TI0NrLkUso6VwaJh1JETHmARLcLul8YrIyojwagL9u g7LdmTNwD4s0u5rsme4fjM1U62mZjLcWuHhfxOXB5MbLVRcU6oAWCvBLZ+9HuTEeBi2p CcNA== X-Gm-Message-State: ACgBeo0cjVvMwXP76bzVPL7cAaFigUdGSmpTdl9N7EY6nBdMALQQlAis YTiJkmAN5N96lPVk8HoTjTLFp+vudz9LaejLlcs= X-Google-Smtp-Source: AA6agR7ZL97vcW7rbdN9c6yFwZ/cXPHi9rSZbEtdWNGKosref5+ypNT+8nvNbTW94t65pcZAsBiIn0JiPOXEBPndKM4= X-Received: by 2002:a17:907:738a:b0:730:7537:848c with SMTP id er10-20020a170907738a00b007307537848cmr8234795ejc.488.1659442018817; Tue, 02 Aug 2022 05:06:58 -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:06:46 +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.1 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:07:01 -0000 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" ;) > I'd be happy to adapt our code, if SCEV can give me useful information. > > Aldy