[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0ky5w82=d2N_iZ2HYujeCDKJJqjT8P25-_+VpsZYWA_A@mail.gmail.com>
Date: Sat, 16 Jul 2022 11:46:59 +0200
From: Arnd Bergmann <arnd@...nel.org>
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: clang-built-linux <llvm@...ts.linux.dev>,
Nathan Chancellor <nathan@...nel.org>,
Miguel Ojeda <ojeda@...nel.org>,
Ard Biesheuval <ardb@...nel.org>, Gary Guo <gary@...yguo.net>,
Russell King <linux@...linux.org.uk>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm: lib: implement aeabi_uldivmod via div64_u64_rem
On Sat, Jul 16, 2022 at 2:16 AM Nick Desaulniers
<ndesaulniers@...gle.com> wrote:
>
> Compilers frequently need to defer 64b division to a libcall with this
> symbol name. It essentially is div64_u64_rem, just with a different
> signature. Kernel developers know to call div64_u64_rem, but compilers
> don't.
>
> Link: https://lore.kernel.org/lkml/20220524004156.0000790e@garyguo.net/
> Suggested-by: Gary Guo <gary@...yguo.net>
> Signed-off-by: Nick Desaulniers <ndesaulniers@...gle.com>
This has historically been strongly NAK'd, and I don't think that position
has changed in the meantime. A variable-argument 64-bit division is
really expensive, especially on 32-bit machines that lack a native
32-bit division instruction, and we don't want developers to accidentally
insert one in their driver code.
Explicitly calling one of the division helpers in linux/math64.h is the
established way for driver writers to declare that a particular division
cannot be turned into a cheaper operation and is never run in a
performance critical code path. The compiler of course cannot know
about either of those.
Arnd
Powered by blists - more mailing lists