From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id 3D22B38582BF for ; Fri, 9 Sep 2022 10:16:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3D22B38582BF Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 4530022411; Fri, 9 Sep 2022 10:16:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1662718587; h=from:from:reply-to: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=2u9XhhfddHoYqRhV4DxEPrwmY/Qrf/6PChC1KtYV2mE=; b=QwgTgiivbf3f7Gcyqzuq6bRuHXjnSDT/JOLu8hf9evOY45a3+PQVsdWjZ4MADxBEgmPTKO f8znChGMa6LGot5CmBEMg4lnKqRB3yxEMDI4WQ13usGrzqsj0064/pWDRYIJZ/5YeuJkub vtTgYfa64XyJ/V12jTEf/KGWxhc45iM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1662718587; h=from:from:reply-to: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=2u9XhhfddHoYqRhV4DxEPrwmY/Qrf/6PChC1KtYV2mE=; b=KFsmBklgemL+uPCC2XEurxeLfxmk5AEGdeWwm0ZSmH/Cu7zXQrG8NtuaC2ew5lHJUOnUls pE3RTqy/7rJd1JAw== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 22C4D2C141; Fri, 9 Sep 2022 10:16:27 +0000 (UTC) Date: Fri, 9 Sep 2022 10:16:27 +0000 (UTC) From: Richard Biener To: Tobias Burnus cc: Andrew Stubbs , Kwok Cheung Yeung , gcc-patches Subject: Re: [PATCH] amdgcn: Add support for additional natively supported floating-point operations In-Reply-To: <08966068-719a-30d1-5b71-7cf839e507e7@codesourcery.com> Message-ID: References: <08966068-719a-30d1-5b71-7cf839e507e7@codesourcery.com> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,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, 9 Sep 2022, Tobias Burnus wrote: > On 09.09.22 10:10, Andrew Stubbs wrote: > On 08.09.22 22:38, Kwok Cheung Yeung wrote: > The instructions for the transcendental functions are documented to have > limited numerical precision, so they are only used if > unsafe_math_optimizations are enabled for now. > > -funsafe-math-optimizations implies -fno-signed-zeros, -fno-trapping-math, > -fassociative-math, > and -freciprocal-math. All of them reduce precision and my violate IEEE or > ISO/language standards. > > However, I think it is rather surprising to have all of the sudden only a > precision of the > order of 100,000,000 ULP instead of ~4 ULP as to be expected. That's a > precision loss of the > order of 10^8 or 2^29 which is huge! > > For program deliberately using double precision, it can be too much ? even if > they do not need > double precision in reality. (Weather forecast system recently moved to single > precision as the > quality is similar and benefits of faster results/finer grids or longer > forecast times prevail.) > > As this behavior is highly surprising, I think it should be at least > documented. > > In https://gcc.gnu.org/PR105246 , I suggested a new flag (such as > -mpermit-reduced-precision) to > make it possible turn it on/off explicitly (might be still enabled by > -funsafe-math-optimizations); > alternatively, it could also be handled as initial guess for the result which > is then refined > in some iteration steps. (It could also be combined to give the user the > choice.) > > While still being convinced that a flag makes more sense than just documenting > it, > I have nonetheless attached a documentation attempt. > > Thoughts? I agree - for example powerpc has -mrecip= to control which instructions to use (float/double rsqrt or inverse) and -mrecip-precision to specify whether further iteration is done or not. x86 has similar but does always perform newton raphson iteration, documenting 2 ulp instead of 0.5 ulp precision. Your suggested huge reduction in precision isn't usually acceptable and should be always explicitely enabled. Richard.