From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) by sourceware.org (Postfix) with ESMTPS id 1F9153857B8A for ; Tue, 8 Nov 2022 17:44:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1F9153857B8A 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-x72f.google.com with SMTP id k4so9533526qkj.8 for ; Tue, 08 Nov 2022 09:44: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=GrNaBGN8KnWsTd2Skp4Sp638n498DF1vicBq7OqVfAA=; b=dLcqcFycqRG7UznLWsDen8eaWkd/Qdnh52Y3GeZn3tCPJ7hovSHeTqxtcLGvCfRACI 32B5IhRV1yXTUCDeKMiExK7QnABvPFcU1MV4zZEHLogSEWv9i4eygmKEZUcW248a2uYw i+1D42KWdRDl7t8lsB30suaQE+ymwyP6NocjNppavvCJoCKoRox9tYPaDBDGZ0j5zD2j pAow61S6KoUYDx5eWWWypuR8KpCfy+5MuVOX0NSfGDlO7vmVVsAX8qVtnH+5YVjln45E 0VA21o3UOZ/knhdspC8DX9VeIb3SI8yBH/HcPnl8u1qxF4Z3bDy0+9Kz5ACyMSJVV9W7 NAHQ== 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=GrNaBGN8KnWsTd2Skp4Sp638n498DF1vicBq7OqVfAA=; b=VnfTB1MVLk9St08iCgc8cAXmo30KsJShrHeoJQad7ijZYpeAA5RJPLumRomhKRP3YH uwKyQR2f+RQzhv6VukVch2IYEuO2Dk96JPLw2SyJREYWoTqK2eLy+GyCk38JfWYUttij uvZ2kVf7nn4rgrZBWSoQ5lcViBeSjSCcs6FJh+BQCp/r6yKgp6jYgnnnX9OFSI/5m0mT kqmZC+5Rkti8Zg+0bOYeowx3Z2jC0m7gZK0vOO+4Q1AxCuLrCI7qG3pZRvuy/009OBky mvTrpgOeNXhagU9BrUn1cjj8rnWq7tkB0naNgGXvHRfn9JYdJT4NP7OfEgjOTySqOK3d kvrw== X-Gm-Message-State: ACrzQf0vXms0xWD2nzgz9UfmqhZrPZGtGemlkEPVhReZlGOLhjrc1VIu 1rFYWJJmIZytYXjPFFmwrAuoiTw0zmhOmgkQRQQcxAMpI3Efjs0eq63x8WPchqmpruqItVK7thf caPiLW5zpg3d3lmbDhPml+QFQCIYAzjqPiIczua5ylCnMxYaPNUAOUmMLNh1DwcBcgHrG X-Google-Smtp-Source: AMsMyM5XEe7CwBEGk14P5asFuuf8yDeeSj5I0ilsVf/gnYfP7dsjls6Fy/A1axDLt97aVaL+hb15JQ== X-Received: by 2002:ae9:e902:0:b0:6fa:8e2c:6c33 with SMTP id x2-20020ae9e902000000b006fa8e2c6c33mr16369708qkf.664.1667929492135; Tue, 08 Nov 2022 09:44:52 -0800 (PST) Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com. [209.85.219.180]) by smtp.gmail.com with ESMTPSA id br8-20020a05620a460800b006cf38fd659asm9764047qkb.103.2022.11.08.09.44.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Nov 2022 09:44:51 -0800 (PST) Received: by mail-yb1-f180.google.com with SMTP id r3so18236986yba.5 for ; Tue, 08 Nov 2022 09:44:51 -0800 (PST) X-Received: by 2002:a25:c1c2:0:b0:6c4:318:642f with SMTP id r185-20020a25c1c2000000b006c40318642fmr51165391ybf.561.1667929491477; Tue, 08 Nov 2022 09:44: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 09:44: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=-3.9 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 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. > > Otherwise LGTM (but would be nice to get into GCC13 not just > +, but also -, *, /, sqrt at least). > > Jakub >