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 9C7A9C433FE for ; Tue, 11 Oct 2022 11:01:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229452AbiJKLBw (ORCPT ); Tue, 11 Oct 2022 07:01:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45196 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229696AbiJKLBt (ORCPT ); Tue, 11 Oct 2022 07:01:49 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6C5468A7F3 for ; Tue, 11 Oct 2022 04:01:48 -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 EAD5CB815A3 for ; Tue, 11 Oct 2022 11:01:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04FA8C433D7; Tue, 11 Oct 2022 11:01:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665486105; bh=7QbwsFF5lAubiJj42U1xHr2EmoYsGUiK17Ub7u1HHxY=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=I3Si+ttKkPoSDW7TYyQ533VRzs4Qlb6t5piGO0X5r+XvJfnpPfWBe4po87ICIksq2 VDg5E4MNtfmKifA2EDzEqLW5AHv2pDiF45+HxByRTuQnA0m/7+hWqsK/GBiu0RBpfW z8dPvm9I317jNAddPCcwleDSGmGU9WlxHjzCMfgcZxGvBV9y5YztEL/qmF8WC+Z9wy e8sARtrNTZe9rMbgwd13U4pDtQEO1cp3doDcRpVLVRfFR0dhC47B1AgrLpphETXBxd JSHgkI6BpvAsyO/IO6dA4Jie8KzBcU2WvHtiFqgcziNuOi3tB5XDKyb+tXDYaUKUFj M0XRYGEpF19XQ== Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id C8D7F27C005A; Tue, 11 Oct 2022 07:01:43 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute3.internal (MEProxy); Tue, 11 Oct 2022 07:01:43 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeejiedgfeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusehkvghrnhgvlhdrohhrgheqnecuggftrf grthhtvghrnheptddvteffleehffeghfeileetudekuedtteevveeuueelleelkeevffef vdeigfegnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrhhnugdomhgvshhmthhprghuthhh phgvrhhsohhnrghlihhthidquddvkeehudejtddvgedqvdekjedttddvieegqdgrrhhnug eppehkvghrnhgvlhdrohhrghesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i36794607:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1FE6FB60086; Tue, 11 Oct 2022 07:01:43 -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: <679c0129-ca59-47a4-aa83-f79ec166951a@app.fastmail.com> In-Reply-To: <20221010225342.3903590-1-ndesaulniers@google.com> References: <20221010225342.3903590-1-ndesaulniers@google.com> Date: Tue, 11 Oct 2022 13:01:22 +0200 From: "Arnd Bergmann" To: "Nick Desaulniers" , "Russell King" Cc: "Tom Rix" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, "Miguel Ojeda" , "Ard Biesheuvel" , "Gary Guo" , "Craig Topper" , "Philip Reames" , jh@jhauser.us, "Nathan Chancellor" Subject: Re: [PATCH] ARM: NWFPE: avoid compiler-generated __aeabi_uldivmod Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 11, 2022, at 12:53 AM, Nick Desaulniers wrote: > clang-15's ability to elide loops completely became more aggressive when > it can deduce how a variable is being updated in a loop. Counting down > one variable by an increment of another can be replaced by a modulo > operation. > > For 64b variables on 32b ARM EABI targets, this can result in the > compiler generating calls to __aeabi_uldivmod, which it does for a do > while loop in float64_rem(). > > For the kernel, we'd generally prefer that developers not open code 64b > division via binary / operators and instead use the more explicit > helpers from div64.h. On arm-linux-gnuabi targets, failure to do so can > result in linkage failures due to undefined references to > __aeabi_uldivmod(). > > While developers can avoid open coding divisions on 64b variables, the > compiler doesn't know that the Linux kernel has a partial implementation > of a compiler runtime (--rtlib) to enforce this convention. > > It's also undecidable for the compiler whether the code in question > would be faster to execute the loop vs elide it and do the 64b division. > > While I actively avoid using the internal -mllvm command line flags, I > think we get better code than using barrier() here, which will force > reloads+spills in the loop for all toolchains. > > Link: https://github.com/ClangBuiltLinux/linux/issues/1666 > Reported-by: Nathan Chancellor > Signed-off-by: Nick Desaulniers Works for me, Reviewed-by: Arnd Bergmann I would have been fine with disallowing NWFPE for clang, or with adding a barrier in the loop as well, i.e. any approach that doesn't cause invalid behavior or a maintenance burden, given that there is probably nobody that actually needs nwfpe on a clang built kernel. Arnd