From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-relay-internal-0.canonical.com (smtp-relay-internal-0.canonical.com [185.125.188.122]) by sourceware.org (Postfix) with ESMTPS id 99D423858D1E for ; Wed, 17 Aug 2022 04:23:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 99D423858D1E Received: from mail-oi1-f199.google.com (mail-oi1-f199.google.com [209.85.167.199]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 14B6E3F11F for ; Wed, 17 Aug 2022 04:23:24 +0000 (UTC) Received: by mail-oi1-f199.google.com with SMTP id s16-20020a0568080b1000b00342fe7c9dfaso3354680oij.6 for ; Tue, 16 Aug 2022 21:23:24 -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=S7cj1SWoC2unAwiGo20jcEmVD3bqnhgpJfJZVMzxB/4=; b=Z9QeOEDi+n1tF56lHfnL2LewSMhJrYwx1umSeYRDPE2PJfmh0fXuYrSlmYQFjul1Cy YAFarI6YsWFJrpByhzkutOmhUYAtkZYxLGVbAo9bWMUN04IrJPYJmtlpYSgju7/z+76/ fFb4dlO4aoVcB1h7wRb8bDZ6wFtqVQeiju1GU57mMbOX2rEFVK6C+iV0iIFBqSZj1eCD QggdZx/CC7+IOW7uXbfUg6vvtwdKQmaxsLQ1HcJZ1bPXhb4DRTIE2CI/aJoBwvUCcQSc 8iPa+NRUtcTQ0zPEwFVm5Mtp0CJYtr7MEQ2z+kKEWP2SAv91sQXR2h4h+BBRkIv6Wvfa +bTg== X-Gm-Message-State: ACgBeo2FOTsnwASjOQWHdDJTS2q5xaDUAwWpA1A5QcI29JG50n5BtGt8 jIYFaCkjksU8jS0pDxZ+t3jsrtHGD07h79PT4GQFi56xQS8eN1Um9kpRb6QN1Bp64E9jMY3AUmi ZG2reAMaCScVtcwmq5pwaO/6MwTAaj1yiSi204H3Kt5fVL9WPJ6Il1w== X-Received: by 2002:a05:6808:23ce:b0:343:85a9:c2ad with SMTP id bq14-20020a05680823ce00b0034385a9c2admr732821oib.13.1660710202875; Tue, 16 Aug 2022 21:23:22 -0700 (PDT) X-Google-Smtp-Source: AA6agR5mAWVkB0YjSgL/3GZ9k1cGTC2O5zVoTGWoQpyA49wAUbotbq93BgT5ko0lMnLKAxNod9nx86hSfArYIz3WymA= X-Received: by 2002:a05:6808:23ce:b0:343:85a9:c2ad with SMTP id bq14-20020a05680823ce00b0034385a9c2admr732813oib.13.1660710202615; Tue, 16 Aug 2022 21:23:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Michael Hudson-Doyle Date: Wed, 17 Aug 2022 16:23:11 +1200 Message-ID: Subject: Re: [PATCH] Ensure calculations happen with desired rounding mode in y1lf128 To: Joseph Myers Cc: Wilco Dijkstra , GNU C Library X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, KAM_NUMSUBJECT, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2022 04:23:27 -0000 On Tue, 16 Aug 2022 at 09:00, Joseph Myers wrote: > On Fri, 12 Aug 2022, Wilco Dijkstra via Libc-alpha wrote: > > > All math functions using the SET_RESTORE_ROUND macros will need similar > > barriers. Sounds fun. Really, wrapping mode changes around a function call sounds saner but also tedious in a different way. > > Note that it is feasible to remove these macros altogether and fix > > any issues (a slightly larger ULP is acceptable for non-nearest > rounding). > Removing the rounding mode change entirely makes the errors quite a lot worse, as the bug Joseph links to shows. > > Given rounding mode changes are generally expensive, this also improves > > performance (though that may not be important for 128-bit floats). > This one is a case where SET_RESTORE_ROUND is used to reduce error > accumulation to keep the errors within the bounds accepted by the > testsuite (see bug 16824). In such cases, it may indeed be possible to > change the algorithm to one that has less total error accumulation > possible in any rounding mode so the results are sufficiently accurate > independent of rounding mode without needing SET_RESTORE_ROUND. > > In other cases, the manipulation of the floating-point environment is > needed for correctness, e.g. to avoid spurious exceptions or to implement > round-to-odd for functions that must be correctly rounding, or it's > because algorithms for higher internal precision are used (Dekker / Knuth) > that are only correct in round-to-nearest most and much larger errors > might occur if those are used in the wrong rounding mode. > It does seem likely that an algorithm that does not require setting a rounding mode would in general be better than one that does but also that this is not very realistic. But I guess my point is that SET_RESTORE_ROUND without barriers is a footgun. I guess I should commit my patch and perhaps see about writing some more for other uses of the macro? Cheers, mwh