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.133.124]) by sourceware.org (Postfix) with ESMTPS id 34ADC3858D32 for ; Mon, 19 Sep 2022 13:04:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 34ADC3858D32 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=1663592669; 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=NsYFGyeQ83syJwmrhxlW197BOSulTl4FEbcKFC1+Hns=; b=hqkm253heOO8pp+CaP9lIRHD1a+T6MK8rxfs0RDJPU0FW8DDV0nSZBWfIyPGPkJTe56Gr3 f6U1wDkou/awo3cpvZzPFQfWAIN4dKLRFFaWKiHGX0WC51b69sfMNSzOtXbRo/Jw8Qu0Gr 8Xk+o6k9IMdc5mRPOoSX0IOicH4UtgE= 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-272-rJuV5LHUMWOQ2vAA7kP-gw-1; Mon, 19 Sep 2022 09:04:28 -0400 X-MC-Unique: rJuV5LHUMWOQ2vAA7kP-gw-1 Received: by mail-oi1-f200.google.com with SMTP id u203-20020acaabd4000000b0034f684ca118so4249877oie.7 for ; Mon, 19 Sep 2022 06:04:28 -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=NsYFGyeQ83syJwmrhxlW197BOSulTl4FEbcKFC1+Hns=; b=3ejZZW5IVzY9YvKlqeUUslawiuP2+QIGUkCJrKToaRJ5ahkeHHFLGyYgT6kIeHel7t 4KhUFXlJGh5j25w5Nqr3H3Sciesin366hSMlzWpz2+D56MJXZ6DFUWjLuwXNgZdyeP52 aIBGvGqJ4r2Q/gh/InmATplalpCOR7+51hfoHF4jiJs+1U/getYBzqbty9j6moyBj7as ET507TOZ6eumewMJdPl1pu/4m9+dyx2lh8wEA2z+zDe4QnR9yTRzz+B5Uc2NHGLHqkYs pfGzcLaKAhrhLdICTRX+XlnqOa6XhkINJVXHosT27wBhIwxdRJAi3kfXayfNRcDcxBGZ +IWA== X-Gm-Message-State: ACgBeo08g3CaZGSvTUF6kO4ixQMVekYJsxgL4PKZhLD6bjFLN8X6foNX AWECQ8/tHX/p4JA0/IVaZ24YHL0r1WUL/ipAOPfHSkb05GYUbkCR5xJA7iRp4j2A8mJbyowLr9V YSyCBdvfpowI7KZhlP6N41vcJLx+4ph4RYg== X-Received: by 2002:a05:6870:160c:b0:12b:9663:67ca with SMTP id b12-20020a056870160c00b0012b966367camr15374030oae.36.1663592666764; Mon, 19 Sep 2022 06:04:26 -0700 (PDT) X-Google-Smtp-Source: AA6agR4qIeurcBbC0cncBHsHo8qGB1Z5JFwgVbzql14sLL2yb1aSaCub9LuDKHZ8RmG5ivAERqZJlWvgl+e3/93OuFY= X-Received: by 2002:a05:6870:160c:b0:12b:9663:67ca with SMTP id b12-20020a056870160c00b0012b966367camr15374012oae.36.1663592666434; Mon, 19 Sep 2022 06:04:26 -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:04:01 +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.0 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 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 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 > > >