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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DBB9BC433FE for ; Tue, 11 Oct 2022 11:03:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:Cc:To:From:Date:References: In-Reply-To:Message-Id:Mime-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=dB2xBQB86Jzs5jc/LcAANID57cNC/XjmlxU5yW7sqEM=; b=KG3h3hADnCOYml mh2p3k2t2WdbWRmGYXK05lqHmU9jqaN/uj3Qav5FB8pV7GaP5gPpcV+m7mOWqt5ReXMkrgTBhs9Mk 79eZLeI9j3U5bM/tOQmQ5LKr334jukKKuhN7xZ8A9WD+orIjmzQLyFL5q/tVGaAvDS+PgaPEpJcJ1 ab1xvrHBbIraz2kR6ySGYGIfq5CJkLV2JTFIdhQuWQMtRHtHEbVSrt4uWkB5xcCeXFeOfMip0z3KF /ULK1/vJAnG4H4DPXqcT9KoxbbqbrSYWTbj0GX+qfYJTL4Am+WLslASv2HFl8uRHV1WE8dhoRCHG4 2AmvsMuEKz3dKOHubTMQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oiD1E-004439-KF; Tue, 11 Oct 2022 11:01:52 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oiD1B-00442f-Uj for linux-arm-kernel@lists.infradead.org; Tue, 11 Oct 2022 11:01:51 +0000 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 dfw.source.kernel.org (Postfix) with ESMTPS id 178F461042; Tue, 11 Oct 2022 11:01:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 11D09C433C1; 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221011_040150_086400_DBB36DC2 X-CRM114-Status: GOOD ( 20.95 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel