From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id B37CF3857C64 for ; Fri, 28 Oct 2022 06:50:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B37CF3857C64 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x630.google.com with SMTP id 13so10830447ejn.3 for ; Thu, 27 Oct 2022 23:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Y+hOTK/Xw7OcAuOl47dPCtu1Mf8RnINtn4EdF32fI68=; b=F2feBxamqLbdZqXIcHE4rPJGXUWXy2nRh8exslK3ZM6NY3AAdvzbXiUhIiOxdGqfIH 1EBJiaU/OQecK1077n3m1C2cIWINEXSgb9S6ofoLSzJvcJ2Xh6vDbvh045uGCPvR52o8 Jqm8kuZVud8JRRNwSvoyyBiIEloOz+nwWhbOt2a1HEYiM0J7ON9Q02mWkc90JwQozyfS 6v2xLw2NuhKH45YrAkzp7oBlUjtX/oeFejdFtsAKw8OArDTTu9ZdyB0T5QhQukxyeINI VphSTjWT2ZnP/d0MwQZlS31aP1MvJqszRe6kB37XVRmRAVhBjxzFa7058boeXBA+8Ssx vTlg== 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:subject:date:message-id :reply-to; bh=Y+hOTK/Xw7OcAuOl47dPCtu1Mf8RnINtn4EdF32fI68=; b=LhItBhd3Iiihs9Y2UVmiRBt57eMXG7y04AFh2/gvH9gLSE3MZv7jf4k88QKVB7LPao OH7aXmCXnFsl+a0puIoh0i4+redp9R7Lj6wJpXQtZ9oN7UyZSKQ09XsPn8UnBYobKx7+ Xa6+3F7QQVEQVmnldWh15I5Dy5gcarQgaCzSLSu6X2Byv/3XqtS0tk1kZB7W+VV7glNc /ixD8t8xKIUe6DET8UiC27FrIlTfMQ8U/bzyneU9pM337cBcL/f1rwb+g+RYZYa3jz5z jXE8iNRTLI+3KiHfvSFoseBeZuKAI6q9vHk6mz4MCzktfmyj3kw6rC7hF+/Y1bgD057K FQmw== X-Gm-Message-State: ACrzQf1UIl2RBgMYXdDKEG3zk9k5ORj/U+oroHfy66DQ3YEm7x/FzKLM 9nvtuCpvGBqKaSq76SmzfGOsEXPA7XiVcxyDpvg= X-Google-Smtp-Source: AMsMyM60XOqruD406Hog/O1EGHuioOUvfgcT/3SSDlIK6MKQtcHvEqdrKcpkNa1VqYfHmWet8iTXyp0/7CEx+NAd+dc= X-Received: by 2002:a17:907:da5:b0:7ad:7e95:6513 with SMTP id go37-20020a1709070da500b007ad7e956513mr10822779ejc.442.1666939829200; Thu, 27 Oct 2022 23:50:29 -0700 (PDT) MIME-Version: 1.0 References: <20221025210140.125230-1-aldyh@redhat.com> In-Reply-To: From: Richard Biener Date: Fri, 28 Oct 2022 08:50:16 +0200 Message-ID: Subject: Re: [PATCH] [PR tree-optimization/107394] Canonicalize global franges as they are read back. To: Jeff Law Cc: Aldy Hernandez , Jakub Jelinek , 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 List-Id: On Fri, Oct 28, 2022 at 8:48 AM Richard Biener wrote: > > On Fri, Oct 28, 2022 at 12:45 AM Jeff Law wrote: > > > > > > On 10/25/22 15:01, Aldy Hernandez via Gcc-patches wrote: > > > [Richi/Jakub/FP experts, does this sound like the right solution, or am I > > > missing some subtle IPA/inlining issue?] > > > > > > The problem here is that we're inlining a global range with NANs into > > > a function that has been tagged with __attribute__((optimize > > > ("-ffinite-math-only"))). As the global range is copied from > > > SSA_NAME_RANGE_INFO, its NAN bits are copied, which then cause > > > frange::verify_range() to fail a sanity check making sure no NANs > > > creep in when !HONOR_NANS. > > > > > > I think what we should do is nuke the NAN bits as we're restoring the > > > global range. For that matter, if we use the frange constructor, > > > everything except that NAN sign will be done automatically, including > > > dropping INFs to the min/max representable range when appropriate. > > > > > > PR tree-optimization/107394 > > > > > > gcc/ChangeLog: > > > > > > * value-range-storage.cc (frange_storage_slot::get_frange): Use > > > frange constructor. > > > > > > gcc/testsuite/ChangeLog: > > > > > > * gcc.dg/tree-ssa/pr107394.c: New test. > > > > The other approach would be to disabling inlining in this case due to an > > unsafe attribute mismatch, but we're not currently doing much sanity > > checking in this space and it might be a huge can of worms. I'm > > inclined to ACK, but give Jakub and Richi until Monday to chime in first. > > We are actually quite careful in this regard but maybe our reasoning > is wrong. We are allowing inlining of -fno-finite-math-only into > -ffinite-math-only code but not the other way around. > > On the actual patch I think that ranges with Inf/NaNs should be always > treated as "valid", the optimization to trim them with certain options > is optimization and thus optional. So IMHO having verify_range ICE > on NaNs isn't correct? Just to make a point here - in functions with -ffinite-math-only in effect volatile double x = __builtin_nan(""); will still have a literal NaN in the IL and that's not invalid GIMPLE. You cannot assume that no NaNs appear with -ffinite-math-only, you just don't need to specially are about preserving them. > That said, the patch is in line with what we do elsewhere at the moment, > so I guess OK. > > Richard. > > > > > jeff > >