From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 045E83858410 for ; Fri, 21 Jul 2023 13:41:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 045E83858410 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 imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id E4F8B2189D; Fri, 21 Jul 2023 13:41:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1689946917; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=067IHp4q7Jaw8oS7SEr24t9RJytW30tYJoMFrZ42s6w=; b=FeVz1k2CB0UeWjrGWgAr3gDI/xmS9WlIECYq9fGoKU/+y+3OB/oAdvpRdbm7AwdcM/JJaN 2ljalr2JMswVihMGUGvjXcjhCtz+Rm4/hwN85LPHlcBUC9rcjAZaCe6stZUWBd0Apd0daY lia+2Z5aT6vjveYSZmPv6HPo30nxP5Q= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1689946917; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=067IHp4q7Jaw8oS7SEr24t9RJytW30tYJoMFrZ42s6w=; b=mHpe+OYl3zoTCRb0+MQRwOJqqAVib5Zg2CuDUSncUGIA/GTp3Exb2tMJBiOLoVTXlEJK7s i1u8xjuDCYe3N/Cg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id D296C134B0; Fri, 21 Jul 2023 13:41:57 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id PYRkMyWLumQbdAAAMHmgww (envelope-from ); Fri, 21 Jul 2023 13:41:57 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: [PATCH] Reduce floating-point difficulties in timevar.cc Date: Fri, 21 Jul 2023 15:41:47 +0200 Message-Id: References: <62d34c82-b883-8497-1b6b-cc662d26b4c9@arm.com> Cc: Xi Ruoyao , gcc-patches@gcc.gnu.org, richard.sandiford@arm.com In-Reply-To: <62d34c82-b883-8497-1b6b-cc662d26b4c9@arm.com> To: Matthew Malcomson X-Mailer: iPhone Mail (20F75) X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: > Am 21.07.2023 um 15:12 schrieb Matthew Malcomson : >=20 > =EF=BB=BFResponding to two emails at the same time ;-) >=20 >> On 7/21/23 13:47, Richard Biener wrote: >>> On Fri, 21 Jul 2023, Matthew Malcomson wrote: >>> On some AArch64 bootstrapped builds, we were getting a flaky test >>> because the floating point operations in `get_time` were being fused >>> with the floating point operations in `timevar_accumulate`. >>>=20 >>> This meant that the rounding behaviour of our multiplication with >>> `ticks_to_msec` was different when used in `timer::start` and when >>> performed in `timer::stop`. These extra inaccuracies led to the >>> testcase `g++.dg/ext/timevar1.C` being flaky on some hardware. >>>=20 >>> This change ensures those operations are not fused and hence stops the t= est >>> being flaky on that particular machine. There is no expected change in t= he >>> generated code. >>> Bootstrap & regtest on AArch64 passes with no regressions. >> I think this is undesriable. With fused you mean we use FMA? >> I think you could use -ffp-contract=3Doff for the TU instead. >=20 > Yeah -- we used fused multiply subtract because we combined the multiply i= n `get_time` with the subtract in `timevar_accumulate`. >=20 >> Note you can't use __attribute__((noinline)) literally since the >> host compiler might not support this. >> Richard. >=20 > On 7/21/23 13:49, Xi Ruoyao wrote: > ... >> I don't think it's correct. It will break bootstrapping GCC from other >> ISO C++11 compilers, you need to at least guard it with #ifdef __GNUC__. >> And IMO it's just hiding the real problem. >> We need more info of the "particular machine". Is this a hardware bug >> (i.e. the machine violates the AArch64 spec) or a GCC code generation >> issue? Or should we generally use -ffp-contract=3Doff in BOOT_CFLAGS? >=20 > My understanding is that this is not a hardware bug and that it's specifie= d that rounding does not happen on the multiply "sub-part" in `FNMSUB`, but r= ounding happens on the `FMUL` that generates some input to it. >=20 > I was given to understand from discussions with others that this codegen i= s allowed -- though I honestly didn't confirm the line of reasoning through a= ll the relevant standards. >=20 >=20 > ------------------------ > W.r.t. both: > Thanks for pointing out bootstrapping from other ISO C++ compilers -- (did= n't realise that was a concern). >=20 > I can look into `-ffp-contract=3Doff` as you both have recommended. > One question -- if we have concerns that the host compiler may not be able= to handle `attribute((noinline))` would we also be concerned that this flag= may not be supported? > (Or is the severity of lack of support sufficiently different in the two c= ases that this is fine -- i.e. not compile vs may trigger floating point rou= nding inaccuracies?) I=E2=80=99d only use it in stage2+ flags where we know we=E2=80=99re dealing= with GCC=20 Richard=20 >=20 >=20