From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 30C7022854 for ; Thu, 29 Aug 2024 17:09:29 +0200 (CEST) Received: (qmail 19520 invoked by uid 550); 29 Aug 2024 15:09:25 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 19480 invoked from network); 29 Aug 2024 15:09:24 -0000 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 23A9340F1DD1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru; s=default; t=1724944156; bh=WlZxq46wHoA9FU/SRf7X4Um2TQpPykm2M84Lr0QPNfI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=DkjP6PLZzMybgPCLq40D9k+otwesyIRD6gu7g/N2VLlkkqhCI1rdYuF1AOpoej5Cw /nDQ7aClz8v+Cuws1Z+FyuPIc5xG20wRsqReIHwzPIJKJvz0BWLpi310vREs08yl0j NtC7Xaq4+brVgpPEt8gMaHaCDy4+gYpK2z2E7nyY= Date: Thu, 29 Aug 2024 18:09:16 +0300 (MSK) From: Alexander Monakov To: =?ISO-8859-15?Q?Alex_R=F8nne_Petersen?= cc: musl@lists.openwall.com In-Reply-To: Message-ID: <78a7c979-19a0-b9bb-95d1-3da2f75322f0@ispras.ru> References: <20240828152826.826990-1-alex@alexrp.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-703270594-1724944156=:5724" Subject: Re: [musl] [PATCH] configure: prevent compilers from turning a * b + c into fma(a, b, c) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-703270594-1724944156=:5724 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Thu, 29 Aug 2024, Alex Rønne Petersen wrote: > That aside, while the motivating issue doesn't (easily) reproduce with > vanilla Clang, it's nonetheless still the case that Clang folds > multiple expressions in `fma()` into `llvm.fmuladd.*` intrinsic calls. > While this might work out in some cases, we've still basically lost at > the LLVM IR level; we're at the mercy of the target backend in regards > to whether it gets lowered to an actual FMA instruction or split back > to the ~original FMUL + FADD. And this isn't even considering what > other nonsense the optimizer pipeline might get up to before that. Thank you for uncovering what was happening in LLVM! I agree there's a backend bug, but the point is moot since disabling FMA contraction globally is the way to go, as discussed in the longer sub-thread. Alexander --8323328-703270594-1724944156=:5724--