From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11329C433F5 for ; Mon, 10 Oct 2022 22:14:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229454AbiJJWOV (ORCPT ); Mon, 10 Oct 2022 18:14:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38772 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229663AbiJJWOT (ORCPT ); Mon, 10 Oct 2022 18:14:19 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 38C5F7F102 for ; Mon, 10 Oct 2022 15:14:18 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 98364B80EBB for ; Mon, 10 Oct 2022 22:14:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9EDAC433B5; Mon, 10 Oct 2022 22:14:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665440055; bh=AkdUwXusUdPpUo4YAW5JR7xyOaeVx/EdiWBZcNyLQP0=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=Qs70pAGUpfL5BAEBOY4oPhLLz+ZO6ZDwRWjOCbzGZynUVwo7gOsa0teg67w3eb9Tk qmOOBGJteXtQ+LmYaxPoUzT5X2Ti+5W2ODo1fGkYnyTqTQLU6w26juAO4xBkhnAI8r QWZXbdNLzSv5/s0nUR7sEeIGC3VUltkmWtHwUd8DvuUAt9gbrKSJCVBTkIx75NyQb2 LtWxwVDfYz3gC86ZzhswGsflPsxCaGkMCkY0XNChtb3whDtTSZdBkF23XvY5Nj9bMD 6yjRPs1D3sjY8ywTw3NfavIYokuYEMZjJ2lJwyWb1Z8XYSV0FtzQ0Auc/Yws1OufXz dHGQfxqTebmuw== Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id B543727C005A; Mon, 10 Oct 2022 18:14:13 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute3.internal (MEProxy); Mon, 10 Oct 2022 18:14:13 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeejhedgtdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusehkvghrnhgvlhdrohhrgheqnecuggftrf grthhtvghrnhepveejleeltdfhudetgfelhfeigffhieekkefgledvteelvdeitedtueet vdegieffnecuffhomhgrihhnpehkvghrnhgvlhdrohhrghdpjhhhrghushgvrhdruhhsne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghrnhgu odhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduvdekhedujedtvdegqddvke ejtddtvdeigedqrghrnhgupeepkhgvrhhnvghlrdhorhhgsegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i36794607:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1E7F6B60086; Mon, 10 Oct 2022 18:14:13 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1015-gaf7d526680-fm-20220929.001-gaf7d5266 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20220716001616.4052225-1-ndesaulniers@google.com> Date: Tue, 11 Oct 2022 00:13:08 +0200 From: "Arnd Bergmann" To: "Nick Desaulniers" Cc: clang-built-linux , "Nathan Chancellor" , "Miguel Ojeda" , "Ard Biesheuvel" , "Gary Guo" , "Russell King" , "Linux ARM" , "Linux Kernel Mailing List" , "Craig Topper" , "Philip Reames" , jh@jhauser.us Subject: Re: [PATCH] arm: lib: implement aeabi_uldivmod via div64_u64_rem Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 10, 2022, at 11:23 PM, Nick Desaulniers wrote: > On Sat, Jul 16, 2022 at 2:47 AM Arnd Bergmann wrote: >> On Sat, Jul 16, 2022 at 2:16 AM Nick Desaulniers wrote: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/nwfpe/softfloat.c#n2312 > Any creative ideas on how to avoid this? Perhaps putting the `aSig -= > bSig;` in inline asm? Inserting a `barrier()` or empty asm statement > into the loops also seems to work. I was going to suggest adding a barrier() as well, should have read on first ;-) > I see this function seems to be based on Berkeley Softfloat > http://www.jhauser.us/arithmetic/SoftFloat.html > v2. v3 looks like a total rewrite. Looking at v3e, it looks like > float64_rem() is now called f64_rem() and defined in f64_rem.c. It > doesn't look like there's anything from v3 that we could backport to > the kernel's v2 to avoid this. > > Otherwise perhaps we just disable OABI_COMPAT for clang. Quite a few > defconfigs explicitly enable FPE_NWFPE though. Are there really a lot > of OABI binaries still in use? I'd do the minimal thing here, neither NWFPE nor OABI_COMPAT should be too relevant here. Russell still uses some machines with old OABI binaries, but I have not heard from anyone else using those in a very long time. Note that while gcc can still produce kernels that are OABI binaries, gcc-4.6 marked the arm-linux-gnu target as obsolete and gcc-4.8 removed it, so any existing binaries were built with toolchains predating that. Arnd