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 A59E43858D32 for ; Mon, 29 Aug 2022 13:13:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A59E43858D32 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=1661778816; 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=9/Rq4J+urcY2dKI/BfIQJVaEdYEdQ9FPb1/+gRTyjsY=; b=Pd51keYTQ9TCTY+ZPVZaGx6mTZmYrpIsp8hgAUAUplD7pBMUQfHAuD3YtZ3/E+uBHW+7eT Zav47bG7GUQGR1kbPwEdxj8iT+kt5bNVANayy010f2GC6dQWJ92LiPzG1JzQnMK6qhdy0b V3RhIqFZVNH8plAH++iBndFCX/Cp2+0= Received: from mail-oi1-f197.google.com (mail-oi1-f197.google.com [209.85.167.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-388-oix3vboYPP-QXAzd7xFw_Q-1; Mon, 29 Aug 2022 09:13:33 -0400 X-MC-Unique: oix3vboYPP-QXAzd7xFw_Q-1 Received: by mail-oi1-f197.google.com with SMTP id l6-20020a544506000000b003455b01ce5dso2510193oil.8 for ; Mon, 29 Aug 2022 06:13:33 -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=9/Rq4J+urcY2dKI/BfIQJVaEdYEdQ9FPb1/+gRTyjsY=; b=mVNyY8ikg5vwE9bd47bAFlu0Ndiml8AB0wdCxvyVXJFQxLOZ1YfiFQi9hTAG7KF+zY S9sNjbwkV2jaXhEzVpHo4OTamvrjhtiEnsxkOmPkwAGOBnOAcBxGaGYdd855Vurhz3oQ hQUfCCMfugyGVtbPQuINnHbeRssNpSv7TkS/mXSuiVV4UKBCBr5+UWFNABt9AyoYi6yj FUzHqmrzDsXwwX1NGRL/sYmHvKwbeO10ScDiu3Z7YDBcWqs0EX0W9pd8rkdrilFju9EL JdNE2lj9g1Z7bu7GYfHblwFibktUNcyRCAgnREL5DTcdALOM2W/TBpKCWc+vXIE1zmG4 rZEw== X-Gm-Message-State: ACgBeo0t75t7Ofs7V27SHvf1hbunsn2ZYvakndT9cEEfKOeotKSkZ+y6 lfbvb3Q21OPIFMi7IMeU2ZRVYUixGwB4/gk70blX+7OxjlYW5By+TtJUla7MlM4KtnsaAze5AAM t0oB4g/DZ6aVZhkfoqmbY2s36FW9qp6wz2A== X-Received: by 2002:a05:6870:210b:b0:10b:ed11:4e2d with SMTP id f11-20020a056870210b00b0010bed114e2dmr7840104oae.265.1661778812696; Mon, 29 Aug 2022 06:13:32 -0700 (PDT) X-Google-Smtp-Source: AA6agR7NNXwUYv3S5etqHJvw59ngBh69ZBpTvfkd0Nvw+ume7eIxV2azcyjPXdtLQ/WdeDOHGeLT6uf+afqyli9V0H8= X-Received: by 2002:a05:6870:210b:b0:10b:ed11:4e2d with SMTP id f11-20020a056870210b00b0010bed114e2dmr7840090oae.265.1661778812421; Mon, 29 Aug 2022 06:13:32 -0700 (PDT) MIME-Version: 1.0 References: <20220826154606.1155977-1-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Mon, 29 Aug 2022 15:13:21 +0200 Message-ID: Subject: Re: [PATCH] [ranger] x == -0.0 does not mean we can replace x with -0.0 To: Jakub Jelinek Cc: GCC patches , Andrew MacLeod X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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, Aug 26, 2022 at 6:40 PM Jakub Jelinek wrote: > > On Fri, Aug 26, 2022 at 05:46:06PM +0200, Aldy Hernandez wrote: > > On the true side of x == -0.0, we can't just blindly value propagate > > the -0.0 into every use of x because x could be +0.0 (or vice versa). > > > > With this change, we only allow the transformation if > > !HONOR_SIGNED_ZEROS or if the range is known not to contain 0. > > > > Will commit after tests complete. > > > > gcc/ChangeLog: > > > > * range-op-float.cc (foperator_equal::op1_range): Do not blindly > > copy op2 range when honoring signed zeros. > > --- > > gcc/range-op-float.cc | 17 +++++++++++++++-- > > 1 file changed, 15 insertions(+), 2 deletions(-) > > > > diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc > > index ad2fae578d2..ff9fe312acf 100644 > > --- a/gcc/range-op-float.cc > > +++ b/gcc/range-op-float.cc > > @@ -252,8 +252,21 @@ foperator_equal::op1_range (frange &r, tree type, > > switch (get_bool_state (r, lhs, type)) > > { > > case BRS_TRUE: > > - // If it's true, the result is the same as OP2. > > - r = op2; > > + if (HONOR_SIGNED_ZEROS (type) > > + && op2.contains_p (build_zero_cst (type))) > > What exactly does op2.contains_p for zero? > Does it use real_compare/real_equal under the hood, so it is > equivalent to op2 == 0.0 or op2 == -0.0, where both will be > true whether op2 is -0.0 or 0.0? Or is it more strict and > checks whether it is actually a positive zero? frange::contains_p() uses real_compare(), so both -0.0 and 0.0 will come out as true: return (real_compare (GE_EXPR, TREE_REAL_CST_PTR (cst), &m_min) && real_compare (LE_EXPR, TREE_REAL_CST_PTR (cst), &m_max)); I thought about this some more, and you're right, dropping to VARYING is a big hammer. It seems to me we can do this optimization regardless, but then treat positive and negative zero the same throughout the frange class. Particularly, in frange::singleton_p(). We should never return TRUE for any version of 0.0. This will keep VRP from propagating an incorrect 0.0, since all VRP does is propagate when a range is provably a singleton. Also, frange::zero_p() shall return true for any version of 0.0. I fleshed out all the relational operators (with endpoints) with this approach, and everything worked out...including go, ada, and fortran, which had given me headaches. As a bonus, we can get rid of the INF/NINF property bits I was keeping around, since now the range will have actual endpoints. I will repost the full frange endpoints patch (and CC you) in the appropriate thread. Aldy > In any case, for HONOR_SIGNED_ZEROS, VARYING is unnecessary, all you > can do is extend the r range to contain both -0.0 and +0.0 if it contains > at least one of them. > > > + { > > + // With signed zeros, x == -0.0 does not mean we can replace > > + // x with -0.0, because x may be either +0.0 or -0.0. > > + r.set_varying (type); > > + } > > + else > > + { > > + // If it's true, the result is the same as OP2. > > + // > > + // If the range does not actually contain zeros, this should > > + // always be OK. > > + r = op2; > > + } > > !HONOR_SIGNED_ZEROS doesn't imply that negative zeros won't appear, > but says that user doesn't care if he gets a positive or negative zero > (unless !MODE_HAS_SIGNED_ZEROS - in that case -0.0 doesn't exist > and one doesn't need to bother with it). > > Now, if all the code setting franges makes sure that for > MODE_HAS_SIGNED_ZEROS && !HONOR_SIGNED_ZEROS if +0.0 or -0.0 are inside > of a range, then both -0.0 and +0.0 are in the range, then yes, > you can use r = op2; > > > // The TRUE side of op1 == op2 implies op1 is !NAN. > > r.set_nan (fp_prop::NO); > > break; > > Jakub >