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.129.124]) by sourceware.org (Postfix) with ESMTPS id C2F1B3856DE8 for ; Tue, 2 Aug 2022 12:11:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C2F1B3856DE8 Received: from mail-oi1-f199.google.com (mail-oi1-f199.google.com [209.85.167.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-175-QVUbby8KMpWUz75kGnoQjA-1; Tue, 02 Aug 2022 08:11:14 -0400 X-MC-Unique: QVUbby8KMpWUz75kGnoQjA-1 Received: by mail-oi1-f199.google.com with SMTP id 17-20020a544191000000b0033a4b6ff677so3808180oiy.1 for ; Tue, 02 Aug 2022 05:11:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=JTkd5HGh/y3Okt+RCO/q6ylIktCwpyMKKornEWyeLm4=; b=dD6bxvYnSquHHpPRKOO4y0Pvwrs2cv77q0RxivtQyeY0fsFO/JGn1M/QLPlH2uYVyh CQk1cZZwOnaVZjSPTb4aGBtjiLJ4tBhC5Up5MFExk5XNwDCtrUZ8rf6RV6xsWX/AOq85 GHemIqLvZYP/yOxjlIb6nL/W+G9r4hZ+P32dlJQ8tzGZ9oVDjiZVtuRVhlpmVaKGJhZm T4jGCPYR3r4O3N5Ay2TTSSxWXNyXvdE/tGo+tJnrjIqdbxVNVHyi52updaysU+uEeTnO 6k9ORzLdR+qJi4HsidX7q01RWMXHarq0T4/h6gam8h13HE1q84KIgl3w/ubt5ZPqgvAf AN9w== X-Gm-Message-State: AJIora9ls91idts0j9aLlkoMs/qasPlDqN/T4gitN7FXRUFAW4w9mSJp sYDeHMpwuZWGRGZ+P80uIzBpEEWURSI38NJ2GGPAdAYA+oMYvHQWJRp84fZxhm7SgkIMNorKKIn rHKl7KtXqKRHSQc/oDs0Z/4cKSE/5Gs9MAg== X-Received: by 2002:a05:6870:210b:b0:10b:ed11:4e2d with SMTP id f11-20020a056870210b00b0010bed114e2dmr9640405oae.265.1659442273413; Tue, 02 Aug 2022 05:11:13 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tPKL7y4swvhfU8rog3VeIRwC0rxamBW4+FeMlHRENwosm8x/hu+dHriEQEpSW9gn/z5vONdIJfiI4rDl7UC4s= X-Received: by 2002:a05:6870:210b:b0:10b:ed11:4e2d with SMTP id f11-20020a056870210b00b0010bed114e2dmr9640392oae.265.1659442273148; Tue, 02 Aug 2022 05:11:13 -0700 (PDT) MIME-Version: 1.0 References: <20220801061540.229684-1-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Tue, 2 Aug 2022 14:11:02 +0200 Message-ID: Subject: Re: [COMMITTED] Make irange dependency explicit for range_of_ssa_name_with_loop_info. To: Richard Biener Cc: "MacLeod, Andrew" , GCC patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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:11:17 -0000 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. Thanks. Aldy