From: Nathan Chancellor <nathan@kernel.org> To: Nick Desaulniers <ndesaulniers@google.com> Cc: Arnd Bergmann <arnd@kernel.org>, Russell King <linux@armlinux.org.uk>, Tom Rix <trix@redhat.com>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, Miguel Ojeda <ojeda@kernel.org>, Ard Biesheuvel <ardb@kernel.org>, Gary Guo <gary@garyguo.net>, Craig Topper <craig.topper@sifive.com>, Philip Reames <listmail@philipreames.com>, jh@jhauser.us Subject: Re: [PATCH] ARM: NWFPE: avoid compiler-generated __aeabi_uldivmod Date: Thu, 13 Oct 2022 10:04:11 -0700 [thread overview] Message-ID: <Y0hFCzVck/zBFwiX@dev-arch.thelio-3990X> (raw) In-Reply-To: <20221010225342.3903590-1-ndesaulniers@google.com> On Mon, Oct 10, 2022 at 03:53:42PM -0700, 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 <nathan@kernel.org> > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> I built ARCH=arm allmodconfig + CONFIG_WERROR=n without this patch and saw the link failure then applied it and the error went away. Thanks for all the investigation done into fixing this! I think you put this in the patch tracker already but just for posterity: Tested-by: Nathan Chancellor <nathan@kernel.org> > --- > arch/arm/nwfpe/Makefile | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/arm/nwfpe/Makefile b/arch/arm/nwfpe/Makefile > index 303400fa2cdf..2aec85ab1e8b 100644 > --- a/arch/arm/nwfpe/Makefile > +++ b/arch/arm/nwfpe/Makefile > @@ -11,3 +11,9 @@ nwfpe-y += fpa11.o fpa11_cpdo.o fpa11_cpdt.o \ > entry.o > > nwfpe-$(CONFIG_FPE_NWFPE_XP) += extended_cpdo.o > + > +# Try really hard to avoid generating calls to __aeabi_uldivmod() from > +# float64_rem() due to loop elision. > +ifdef CONFIG_CC_IS_CLANG > +CFLAGS_softfloat.o += -mllvm -replexitval=never > +endif > -- > 2.38.0.rc2.412.g84df46c1b4-goog >
WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <nathan@kernel.org> To: Nick Desaulniers <ndesaulniers@google.com> Cc: Arnd Bergmann <arnd@kernel.org>, Russell King <linux@armlinux.org.uk>, Tom Rix <trix@redhat.com>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, Miguel Ojeda <ojeda@kernel.org>, Ard Biesheuvel <ardb@kernel.org>, Gary Guo <gary@garyguo.net>, Craig Topper <craig.topper@sifive.com>, Philip Reames <listmail@philipreames.com>, jh@jhauser.us Subject: Re: [PATCH] ARM: NWFPE: avoid compiler-generated __aeabi_uldivmod Date: Thu, 13 Oct 2022 10:04:11 -0700 [thread overview] Message-ID: <Y0hFCzVck/zBFwiX@dev-arch.thelio-3990X> (raw) In-Reply-To: <20221010225342.3903590-1-ndesaulniers@google.com> On Mon, Oct 10, 2022 at 03:53:42PM -0700, 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 <nathan@kernel.org> > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> I built ARCH=arm allmodconfig + CONFIG_WERROR=n without this patch and saw the link failure then applied it and the error went away. Thanks for all the investigation done into fixing this! I think you put this in the patch tracker already but just for posterity: Tested-by: Nathan Chancellor <nathan@kernel.org> > --- > arch/arm/nwfpe/Makefile | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/arm/nwfpe/Makefile b/arch/arm/nwfpe/Makefile > index 303400fa2cdf..2aec85ab1e8b 100644 > --- a/arch/arm/nwfpe/Makefile > +++ b/arch/arm/nwfpe/Makefile > @@ -11,3 +11,9 @@ nwfpe-y += fpa11.o fpa11_cpdo.o fpa11_cpdt.o \ > entry.o > > nwfpe-$(CONFIG_FPE_NWFPE_XP) += extended_cpdo.o > + > +# Try really hard to avoid generating calls to __aeabi_uldivmod() from > +# float64_rem() due to loop elision. > +ifdef CONFIG_CC_IS_CLANG > +CFLAGS_softfloat.o += -mllvm -replexitval=never > +endif > -- > 2.38.0.rc2.412.g84df46c1b4-goog > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-10-13 17:04 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-07-16 0:16 [PATCH] arm: lib: implement aeabi_uldivmod via div64_u64_rem Nick Desaulniers 2022-07-16 0:16 ` Nick Desaulniers 2022-07-16 0:16 ` Nick Desaulniers 2022-07-16 9:46 ` Arnd Bergmann 2022-07-16 9:46 ` Arnd Bergmann 2022-10-10 21:23 ` Nick Desaulniers 2022-10-10 21:23 ` Nick Desaulniers 2022-10-10 22:13 ` Arnd Bergmann 2022-10-10 22:13 ` Arnd Bergmann 2022-10-10 22:34 ` Nick Desaulniers 2022-10-10 22:34 ` Nick Desaulniers 2022-10-10 22:53 ` [PATCH] ARM: NWFPE: avoid compiler-generated __aeabi_uldivmod Nick Desaulniers 2022-10-10 22:53 ` Nick Desaulniers 2022-10-11 11:01 ` Arnd Bergmann 2022-10-11 11:01 ` Arnd Bergmann 2022-10-13 17:04 ` Nathan Chancellor [this message] 2022-10-13 17:04 ` Nathan Chancellor 2022-07-18 16:50 ` [PATCH] arm: lib: implement aeabi_uldivmod via div64_u64_rem kernel test robot 2022-07-18 16:50 ` kernel test robot
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Y0hFCzVck/zBFwiX@dev-arch.thelio-3990X \ --to=nathan@kernel.org \ --cc=ardb@kernel.org \ --cc=arnd@kernel.org \ --cc=craig.topper@sifive.com \ --cc=gary@garyguo.net \ --cc=jh@jhauser.us \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=listmail@philipreames.com \ --cc=llvm@lists.linux.dev \ --cc=ndesaulniers@google.com \ --cc=ojeda@kernel.org \ --cc=trix@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.