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 13B883858C62 for ; Mon, 7 Nov 2022 12:35:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 13B883858C62 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=1667824550; 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=o0xh2VT/UxMU+iF7z5SkOzTexKxqBDF4A7ZUZmPnkuE=; b=Sv4M8UDTpp0dy7RNKZhJK5KnBtLzBpqQrs5rzgex3oJIOufk2uck106WtJSBrQ373Hkg23 0z5HyIe6Xns5uM/UayC/280zYoSTCKS0Y7ASZYHDfICMrAi/3aPxCmmIx4+LrT2DOX5Q1m 2A4TUS/2CjCosJ0g7EXYrYFdWuyZsTY= Received: from mail-yw1-f199.google.com (mail-yw1-f199.google.com [209.85.128.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-491-GrJyX3cSMpuZMoPUvzLsVg-1; Mon, 07 Nov 2022 07:35:48 -0500 X-MC-Unique: GrJyX3cSMpuZMoPUvzLsVg-1 Received: by mail-yw1-f199.google.com with SMTP id 00721157ae682-3735edd4083so106994377b3.0 for ; Mon, 07 Nov 2022 04:35:48 -0800 (PST) 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=o0xh2VT/UxMU+iF7z5SkOzTexKxqBDF4A7ZUZmPnkuE=; b=n5k6IgqeW9Ygnd1VC/0z3jSSJen6yQeam0BCAH2/r6LMbYXPz8vPDeQLhMh3f1+Wij YcKypNoV2JryfnYtoImJJXP+zvd59Zd1D1evFXp2Mr+KeNQuLy0lOrV8nAP+7URkhxy3 fq8CmStfQY/3bi44/g+46fv7+t6XQJUtYIa1sLXtkSTvG7JfI6ql22f8xV93RK2V+LWy xuLrqKWTu5fUYYRa5Hg1ZgmTYS7TExu7BRuBCWIlW7JQY5rhOx+7iKm6qdN/0aFiGRT2 qF49tZm5TSNAXzyZdB+1UKJVxxKa0FbonksLprPvipFoBMjRsicgvgzt9xMcUXlSa9mq Yuzw== X-Gm-Message-State: ACrzQf0rCb5sHe+kNL4bgB8nTdsc7vN+9lf4NnGHns+b8TBWfCRJtjse Hpum4AQY3hDQUBuCDCn83zuWq00D6zG1Fa599col0QTeWJkGgsVhTud6P5zWIQYU9stD+QnMri3 7PB9mEv+w1njOV9gzGtFrFBK7DrcI1pzjfw== X-Received: by 2002:a25:df10:0:b0:6cf:f148:7cdb with SMTP id w16-20020a25df10000000b006cff1487cdbmr27854553ybg.80.1667824547900; Mon, 07 Nov 2022 04:35:47 -0800 (PST) X-Google-Smtp-Source: AMsMyM5cBQ/gRKn114vx6NM7ISLb/PBdQt2gAIXRC68HrQ21+j5x3NQecEPa64U7CeGISd7RslNo8r4u+Eep9n12FNM= X-Received: by 2002:a25:df10:0:b0:6cf:f148:7cdb with SMTP id w16-20020a25df10000000b006cff1487cdbmr27854534ybg.80.1667824547603; Mon, 07 Nov 2022 04:35:47 -0800 (PST) MIME-Version: 1.0 References: <20221013123649.474497-1-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Mon, 7 Nov 2022 13:35:35 +0100 Message-ID: Subject: Re: [PATCH] [PR24021] Implement PLUS_EXPR range-op entry for floats. To: Jakub Jelinek , "MacLeod, Andrew" Cc: GCC patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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 Fri, Nov 4, 2022 at 8:53 PM Jakub Jelinek wrote: > > On Fri, Nov 04, 2022 at 08:14:23PM +0100, Jakub Jelinek via Gcc-patches wrote: > > One thing that is clear is that real_isdenormal is never true for these > > (but then a question is if flush_denormals_to_zero actually works). > > So, after some more investigation, I think that is actually the case, > real_isdenormal is only meaningful (will ever return true) right after > round_for_format. > The uses inside of real.cc are fine, real_to_target first calls > round_for_format and then calls fmt->encode in which the real_isdenormal > calls are done. And, round_for_format is what transforms the > normalized way of expressing the number into the denormal form: > /* Check the range of the exponent. If we're out of range, > either underflow or overflow. */ > if (REAL_EXP (r) > emax2) > goto overflow; > else if (REAL_EXP (r) <= emin2m1) > { > int diff; > > if (!fmt->has_denorm) > { > /* Don't underflow completely until we've had a chance to round. */ > if (REAL_EXP (r) < emin2m1) > goto underflow; > } > else > { > diff = emin2m1 - REAL_EXP (r) + 1; > if (diff > p2) > goto underflow; > > /* De-normalize the significand. */ > r->sig[0] |= sticky_rshift_significand (r, r, diff); > SET_REAL_EXP (r, REAL_EXP (r) + diff); > } > } > But, real_to_target is one of the 4 callers of static round_for_format, > another one is real_convert, but that one undoes that immediately: > round_for_format (fmt, r); > > /* Make resulting NaN value to be qNaN. The caller has the > responsibility to avoid the operation if flag_signaling_nans > is on. */ > if (r->cl == rvc_nan) > r->signalling = 0; > > /* round_for_format de-normalizes denormals. Undo just that part. */ > if (r->cl == rvc_normal) > normalize (r); > and the last two are inside of encoding the IBM double double composite. > So, I think everywhere in the frange you'll see normalized REAL_VALUE_TYPE > and so real_isdenormal will always be false there. > You need to check for REAL_EXP (r) < fmt->emin or so (and ideally only on > REAL_VALUE_TYPE already real_converted to the right mode (your > frange_arithmetics does that already, which is good, but say conversions > and other unary ops might need it too). Let me see if I understand you correctly... real_isdenormal is always returning false for our uses in frange? So instead of using real_isdenormal in flush_denormals_to_zero, perhaps we should be using: REAL_EXP (r) < REAL_MODE_FORMAT (mode)->emin ?? Could we perhaps make real_isdenormal always work for all values? Is that possible? Aldy