From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) by sourceware.org (Postfix) with ESMTPS id 73C163858D32 for ; Tue, 8 Nov 2022 18:17:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 73C163858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-qk1-x735.google.com with SMTP id x21so9624246qkj.0 for ; Tue, 08 Nov 2022 10:17:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=T2KmPN9fzJ6uvy26mGIfEYZjmNTl8+8N2sR5Sfr6Sck=; b=EPo1Dt/P3By4MyfesDxPYnu06fgH9whxVXl9601o5xEPrRld+LnfuffDQlHwzi7jFR vi53IHdKes9BCjNLDMZdnfVRCDL+apRMq9PAjLjMwugAZxetKQo8u4B1ktg6PG6JaJ1i IJADrPfUh4fDWcNhKB+mYe1ZjiTILExOplKbD2mcmoc5RYlkAcA71U41GsP3sItd4Xga TjqFIKGQW9Q7om+rR+NIHPnmDmw0sbSWH8x9r0ZoeWW6gPOa+q7ba1tsIt2OZi8CCsw8 1f+ZvJ0CgdMW45gQTqt4UHAlIjkm7LTLCFaoGtkKH74aR8nHKqcReJHZSH+z5nqdOL8B 35WA== 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=T2KmPN9fzJ6uvy26mGIfEYZjmNTl8+8N2sR5Sfr6Sck=; b=rP1dRkzABHF0CB1Cf73/f/48WiL2VqEzHQoIJSVm/rhoUtjyHXethfOEBHSqDWPpib iAL+AVwO2RRSmdRC97sPn+Vu14T5sflibIOcoA6SDa76LzlTCR/aN8shvMiuawjeGays LcxyO+eyLrHw73mTfu20+D603CFcf/OiaIDc122G1Zv4VJJXhY7x6LfM3wUrqOQy/bPH 6Am4BSg+2DQGUKIujuHKuA3CbVxTe6+HKPuYBtRaJJIE/45NEJ47Ueu1N6DCIwm/Iqxu 1Qg1t7OL9d9ToyHriydN8yq/3bJTlVkKa3zDRzI3EsuzEphsTKfGZF2z4/SaNjI+q5OC KYbw== X-Gm-Message-State: ACrzQf23UnsbUl3d03vfFf7KFr8SeFl8oYrTJ4TV3xOOjt93/4FPwSVT ii4Y2OZuPAybvXvL89N4P8GPiRvVfJLjkVq+BI7O0DYweRBLS5b4wKgMiFy6FCqbjFF9fRTASSb Osu0CCV9KYsDetR6FBaguYEgIrL71qhNclgyyik4ngN+4qKmRp0il8BRiIuxQUrsCJt2d X-Google-Smtp-Source: AMsMyM6t1UhisweovJP2baYeih8LUKItI+Nx48A3E73AyELx0nkqyzTVjkwZAjCa7EdsKyXuvjOuew== X-Received: by 2002:ae9:d846:0:b0:6fa:f72:66f3 with SMTP id u67-20020ae9d846000000b006fa0f7266f3mr40367803qkf.522.1667931472478; Tue, 08 Nov 2022 10:17:52 -0800 (PST) Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com. [209.85.128.170]) by smtp.gmail.com with ESMTPSA id fa13-20020a05622a4ccd00b0039cc22a2c49sm8570997qtb.47.2022.11.08.10.17.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Nov 2022 10:17:52 -0800 (PST) Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-3321c2a8d4cso141417197b3.5 for ; Tue, 08 Nov 2022 10:17:52 -0800 (PST) X-Received: by 2002:a81:a190:0:b0:36c:231:95ac with SMTP id y138-20020a81a190000000b0036c023195acmr52185277ywg.10.1667931471816; Tue, 08 Nov 2022 10:17:51 -0800 (PST) MIME-Version: 1.0 References: <20221013123649.474497-1-aldyh@redhat.com> In-Reply-To: From: Andrew Waterman Date: Tue, 8 Nov 2022 10:17:40 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] [PR24021] Implement PLUS_EXPR range-op entry for floats. To: Jakub Jelinek Cc: Aldy Hernandez , GCC patches , Andrew MacLeod Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 Tue, Nov 8, 2022 at 10:11 AM Jakub Jelinek wrote: > > On Tue, Nov 08, 2022 at 09:44:40AM -0800, Andrew Waterman wrote: > > On Tue, Nov 8, 2022 at 3:20 AM Jakub Jelinek via Gcc-patches > > wrote: > > > > > > On Mon, Nov 07, 2022 at 04:41:23PM +0100, Aldy Hernandez wrote: > > > > As suggested upthread, I have also adjusted update_nan_sign() to drop > > > > the NAN sign to VARYING if both operands are NAN. As an optimization > > > > I keep the sign if both operands are NAN and have the same sign. > > > > > > For NaNs this still relies on something IEEE754 doesn't guarantee, > > > as I cited, after a binary operation the sign bit of the NaN is > > > unspecified, whether there is one NaN operand or two. > > > It might be that all CPUs handle it the way you've implemented > > > (that for one NaN operand the sign of NaN result will be the same > > > as that NaN operand and for two it will be the sign of one of the two > > > NaNs operands, never something else), but I think we'd need to check > > > more than one implementation for that (I've only tried x86_64 and thus > > > SSE behavior in it), so one would need to test i387 long double behavior > > > too, ARM/AArch64, PowerPC, s390{,x}, RISCV, ... > > > The guarantee given by IEEE754 is only for those copy, negate, abs, copySign > > > operations, so copying values around, NEG_EXPR, ABS_EXPR, __builtin_fabs*, > > > __builtin_copysign*. > > > > FWIW, RISC-V canonicalizes NaNs by clearing the sign bit; the signs of > > the input NaNs do not factor in. > > Just for binary operations and some unary, or also the ones that > IEEE754 spells out (moves, negations, absolute value and copysign)? I should've been more specific in my earlier email: I was referring to the arithmetic operators. Copysign and friends do not canonicalize NaNs. > > Jakub >