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 3E8B73858D1E for ; Mon, 19 Sep 2022 13:07:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3E8B73858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663592824; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kD6OOE002wCAlqAe+iomSuUoF4prSWeJGmMYEo4eXxY=; b=d2VxyDvh69z/VuHQ1zGDIICT7BxmUPx3DKI0Jc/e6BDhuMGuMq0XkpZKH4vs5P326qIKR1 E3PCfZYORQj2QYQ2BtQcEuhG06AEimClVzgzRgmWUBWwWW15dLkUZ4uxY6jwzFadfo/W1q K3T+ipmqSHHGZFDuRsXL9eON/EEi7/0= Received: from mail-oi1-f200.google.com (mail-oi1-f200.google.com [209.85.167.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-533-8k44vTUsPrmQ8K6MLKBOGw-1; Mon, 19 Sep 2022 09:07:03 -0400 X-MC-Unique: 8k44vTUsPrmQ8K6MLKBOGw-1 Received: by mail-oi1-f200.google.com with SMTP id h133-20020aca3a8b000000b00350c126bf48so475972oia.23 for ; Mon, 19 Sep 2022 06:07:03 -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:subject:date; bh=kD6OOE002wCAlqAe+iomSuUoF4prSWeJGmMYEo4eXxY=; b=V1Eb+egd0PvNMPL2cFLznPYwBAGLzZTILPQXHIeELSM6tlNKUGdGkD8i5vMCj/o/gU G56gWgwy36XfonsAnAJH9tXAGmYh09hBIlkL8vMEXwk1DUoL9XUU3XYyXw6EttOrqMzJ e1fLNFCqGqt+MTK3F2fiSsEFUNcSnF5n6ekHSlM6GTYfLStt+fZHDEjNHitAVtAD8Y2K jrwRp4tihBzPRvUjtush08vlVPh6xkycc98AAYQw5yHUM9Irl+fDKWIQEnCJweR/k8Bk W/t4Cj9JnB8jYwFPjx82z+GOi1RdQs/YOA/zxKULJb5mP8AvQD0r8MatZ2rFWOc1iNQU 4Yqw== X-Gm-Message-State: ACgBeo03/jxwRwh3AYRWQ/OjJ49MnKPyjUI+p588nv/nhjhm1+obFj6u K68v9lJ5bvZUjyMcdKia32bbe+8nCA45zjXf2KrX+lP0wZd5FWR4OMMwX2x3KmFnt0aftW86VH7 ziqUTjEjrve2hn53Zf1H0MidSyAnUUSr6UA== X-Received: by 2002:a05:6870:160c:b0:12b:9663:67ca with SMTP id b12-20020a056870160c00b0012b966367camr15382357oae.36.1663592823167; Mon, 19 Sep 2022 06:07:03 -0700 (PDT) X-Google-Smtp-Source: AA6agR7l/he9iaUhWpq03ehyV94tph1XZRMW3BIKy5fGGBF1Qn+hKPnBgQ5LKN+s/OyYQ6yjnPLcCJB8/Txk+sUsQdU= X-Received: by 2002:a05:6870:160c:b0:12b:9663:67ca with SMTP id b12-20020a056870160c00b0012b966367camr15382340oae.36.1663592822913; Mon, 19 Sep 2022 06:07:02 -0700 (PDT) MIME-Version: 1.0 References: <20220917082403.1573721-1-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Mon, 19 Sep 2022 15:06:51 +0200 Message-ID: Subject: Re: [PATCH] frange: flush denormals to zero for -funsafe-math-optimizations. To: Richard Biener Cc: Jakub Jelinek , Richard Henderson , GCC patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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 List-Id: On Mon, Sep 19, 2022 at 3:04 PM Aldy Hernandez wrote: > > On Mon, Sep 19, 2022 at 9:37 AM Richard Biener > wrote: > > > > On Sat, Sep 17, 2022 at 10:25 AM Aldy Hernandez via Gcc-patches > > wrote: > > > > > > Jakub has mentioned that for -funsafe-math-optimizations we may flush > > > denormals to zero, in which case we need to be careful to extend the > > > ranges to the appropriate zero. This patch does exactly that. For a > > > range of [x, -DENORMAL] we flush to [x, -0.0] and for [+DENORMAL, x] > > > we flush to [+0.0, x]. > > > > > > It is unclear whether we should do this for Alpha, since I believe > > > flushing to zero is the default, and the port requires -mieee for IEEE > > > sanity. If so, perhaps we should add a target hook so backends are > > > free to request flushing to zero. > > > > > > Thoughts? > > > > I'm not sure what the intention of this is - it effectively results in > > more conservative ranges for -funsafe-math-optimizations. That is, > > if -funsafe-math-optimizations says that denormals don't exist and > > are all zero then doesn't that mean we can instead use the smalles > > non-denormal number less than (or greater than) zero here? > > > > That said, the flushing you do is also "valid" for > > -fno-unsafe-math-optimizations > > in case we don't want to deal with denormals in range boundaries. > > > > It might also be a correctness requirement in case we don't know how > > targets handle denormals (IIRC even OS defaults might matter here) so > > we conservatively have to treat them as being flushed to zero. > > Actually, rth suggested we always flush to zero because we don't know > what the target would do. Again, I'm happy to do whatever you agree More specifically, we don't know what the OS will do, so we either should have a flag of some kind set to TRUE by default when unsafe math optimizations, or always assume denormal flushing could happen. Again, no opinion. Up to y'all. Aldy > on. I have no opinion. My main goal here is correctness. > > > > > So ... if we want to be on the "safe" side then please always do this. > > > > At the same point you could do > > > > if (!HONOR_SIGNED_ZEROS ()) > > if (real_iszero (&m_max)) > > { > > if (real_iszero (&m_min)) > > m.min.sign = 1; > > m_max.sign = 1; > > } > > But wouldn't that set [-0.0, -0.0] when encountering [+0, +0] ?? > > > else if (real_iszero (&m_min)) > > m_min.sign = 0; > > Jakub actually suggested something completely different...just set +0 > always for !HONOR_SIGNED_ZEROS. > > Aldy > > > > > so that we canonicalize a zero bound so that the sign is known for a range. > > > > Richard. > > > > > gcc/ChangeLog: > > > > > > * value-range.cc (frange::flush_denormals_to_zero): New. > > > (frange::set): Call flush_denormals_to_zero. > > > * value-range.h (class frange): Add flush_denormals_to_zero. > > > --- > > > gcc/value-range.cc | 24 ++++++++++++++++++++++++ > > > gcc/value-range.h | 1 + > > > 2 files changed, 25 insertions(+) > > > > > > diff --git a/gcc/value-range.cc b/gcc/value-range.cc > > > index 67d5d7fa90f..f285734f0e0 100644 > > > --- a/gcc/value-range.cc > > > +++ b/gcc/value-range.cc > > > @@ -267,6 +267,26 @@ tree_compare (tree_code code, tree op1, tree op2) > > > return !integer_zerop (fold_build2 (code, integer_type_node, op1, op2)); > > > } > > > > > > +// Flush denormal endpoints to the appropriate 0.0. > > > + > > > +void > > > +frange::flush_denormals_to_zero () > > > +{ > > > + if (undefined_p () || known_isnan ()) > > > + return; > > > + > > > + // Flush [x, -DENORMAL] to [x, -0.0]. > > > + if (real_isdenormal (&m_max) && real_isneg (&m_max)) > > > + { > > > + m_max = dconst0; > > > + if (HONOR_SIGNED_ZEROS (m_type)) > > > + m_max.sign = 1; > > > + } > > > + // Flush [+DENORMAL, x] to [+0.0, x]. > > > + if (real_isdenormal (&m_min) && !real_isneg (&m_min)) > > > + m_min = dconst0; > > > +} > > > + > > > // Setter for franges. > > > > > > void > > > @@ -317,6 +337,10 @@ frange::set (tree min, tree max, value_range_kind kind) > > > gcc_checking_assert (tree_compare (LE_EXPR, min, max)); > > > > > > normalize_kind (); > > > + > > > + if (flag_unsafe_math_optimizations) > > > + flush_denormals_to_zero (); > > > + > > > if (flag_checking) > > > verify_range (); > > > } > > > diff --git a/gcc/value-range.h b/gcc/value-range.h > > > index 3a401f3e4e2..795b1f00fdc 100644 > > > --- a/gcc/value-range.h > > > +++ b/gcc/value-range.h > > > @@ -327,6 +327,7 @@ private: > > > bool union_nans (const frange &); > > > bool intersect_nans (const frange &); > > > bool combine_zeros (const frange &, bool union_p); > > > + void flush_denormals_to_zero (); > > > > > > tree m_type; > > > REAL_VALUE_TYPE m_min; > > > -- > > > 2.37.1 > > > > >