From: Nathan Chancellor <natechancellor@gmail.com> To: Adrian Ratiu <adrian.ratiu@collabora.com> Cc: Arnd Bergmann <arnd@arndb.de>, linux-arm-kernel@lists.infradead.org, Nick Desaulniers <ndesaulniers@google.com>, clang-built-linux@googlegroups.com, Russell King <linux@armlinux.org.uk>, linux-kernel@vger.kernel.org, kernel@collabora.com, Ard Biesheuvel <ardb@kernel.org> Subject: Re: [PATCH 2/2] arm: lib: xor-neon: disable clang vectorization Date: Fri, 6 Nov 2020 11:01:15 -0700 [thread overview] Message-ID: <20201106180115.GB2959494@ubuntu-m3-large-x86> (raw) In-Reply-To: <87wnyyvh56.fsf@collabora.com> Hi Adrian, On Fri, Nov 06, 2020 at 01:50:13PM +0200, Adrian Ratiu wrote: > I tested Arnd's kernel patch from the LLVM bugtracker [1], but with the > Clang v10.0.1 I still get warnings like the following even though the > __restrict workaround seems to affect the generated instructions: > > ./include/asm-generic/xor.h:15:2: remark: the cost-model indicates that > interleaving is not beneficial [-Rpass-missed=loop-vectorize] > ./include/asm-generic/xor.h:11:1: remark: List vectorization was possible > but not beneficial with cost 0 >= 0 [-Rpass-missed=slp-vectorizer] > xor_8regs_2(unsigned long bytes, unsigned long *__restrict p1, unsigned long > *__restrict p2) > > [1] https://bugs.llvm.org/show_bug.cgi?id=40976#c6 Ack, thanks for double checking! > In my opinion we have 3 ways to go regarding this: > > 1. Leave it as is and try to notify the user of the breakage (eg add a new > warning). You previously said this is not a good idea because the user can't > do anything about it. I agree. > > 2. Somehow work around the compiler bug in the kernel which is what the LLVM > bugtracker patch tries to do. This is a slippery slope even if we somehow > get it right, especially since multiple Clang versions might be supported in > the future and we don't know when the bug will be properly fixed by the > compiler. In addition we're enabling and "hiding" possibly undefined > behaviour. > > 3. Disable the broken feature and once the compiler bug is fixed enable it > back warning users of old compilers that there is an action they can take: > upgrade. This is exactly how this was handled for GCC previously, so there > is a precedent. > > This implements the 3'rd scenario which is also the first thing Arnd > suggested in the original patch. :) I agree that number three is definitely the most robust against the future. I know that I periodically grep the tree for "bugs.llvm.org" because we always file something on LLVM's bug tracker when we have to work around something in the kernel. I think this patch is totally fine as is, hopefully we can get it fixed in LLVM sooner rather than later. Cheers, Nathan
WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <natechancellor@gmail.com> To: Adrian Ratiu <adrian.ratiu@collabora.com> Cc: Arnd Bergmann <arnd@arndb.de>, Nick Desaulniers <ndesaulniers@google.com>, linux-kernel@vger.kernel.org, Russell King <linux@armlinux.org.uk>, clang-built-linux@googlegroups.com, kernel@collabora.com, Ard Biesheuvel <ardb@kernel.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 2/2] arm: lib: xor-neon: disable clang vectorization Date: Fri, 6 Nov 2020 11:01:15 -0700 [thread overview] Message-ID: <20201106180115.GB2959494@ubuntu-m3-large-x86> (raw) In-Reply-To: <87wnyyvh56.fsf@collabora.com> Hi Adrian, On Fri, Nov 06, 2020 at 01:50:13PM +0200, Adrian Ratiu wrote: > I tested Arnd's kernel patch from the LLVM bugtracker [1], but with the > Clang v10.0.1 I still get warnings like the following even though the > __restrict workaround seems to affect the generated instructions: > > ./include/asm-generic/xor.h:15:2: remark: the cost-model indicates that > interleaving is not beneficial [-Rpass-missed=loop-vectorize] > ./include/asm-generic/xor.h:11:1: remark: List vectorization was possible > but not beneficial with cost 0 >= 0 [-Rpass-missed=slp-vectorizer] > xor_8regs_2(unsigned long bytes, unsigned long *__restrict p1, unsigned long > *__restrict p2) > > [1] https://bugs.llvm.org/show_bug.cgi?id=40976#c6 Ack, thanks for double checking! > In my opinion we have 3 ways to go regarding this: > > 1. Leave it as is and try to notify the user of the breakage (eg add a new > warning). You previously said this is not a good idea because the user can't > do anything about it. I agree. > > 2. Somehow work around the compiler bug in the kernel which is what the LLVM > bugtracker patch tries to do. This is a slippery slope even if we somehow > get it right, especially since multiple Clang versions might be supported in > the future and we don't know when the bug will be properly fixed by the > compiler. In addition we're enabling and "hiding" possibly undefined > behaviour. > > 3. Disable the broken feature and once the compiler bug is fixed enable it > back warning users of old compilers that there is an action they can take: > upgrade. This is exactly how this was handled for GCC previously, so there > is a precedent. > > This implements the 3'rd scenario which is also the first thing Arnd > suggested in the original patch. :) I agree that number three is definitely the most robust against the future. I know that I periodically grep the tree for "bugs.llvm.org" because we always file something on LLVM's bug tracker when we have to work around something in the kernel. I think this patch is totally fine as is, hopefully we can get it fixed in LLVM sooner rather than later. Cheers, Nathan _______________________________________________ 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:[~2020-11-06 18:01 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-06 5:14 [PATCH 0/2] arm: lib: xor-neon: Remove warn & disble neon vect Adrian Ratiu 2020-11-06 5:14 ` Adrian Ratiu 2020-11-06 5:14 ` [PATCH 1/2] arm: lib: xor-neon: remove unnecessary GCC < 4.6 warning Adrian Ratiu 2020-11-06 5:14 ` Adrian Ratiu 2020-11-06 14:46 ` Arnd Bergmann 2020-11-06 14:46 ` Arnd Bergmann 2020-11-06 18:03 ` Nathan Chancellor 2020-11-06 18:03 ` Nathan Chancellor 2020-11-06 21:46 ` Arnd Bergmann 2020-11-06 21:46 ` Arnd Bergmann 2020-11-06 5:14 ` [PATCH 2/2] arm: lib: xor-neon: disable clang vectorization Adrian Ratiu 2020-11-06 5:14 ` Adrian Ratiu 2020-11-06 10:14 ` Nathan Chancellor 2020-11-06 10:14 ` Nathan Chancellor 2020-11-06 11:50 ` Adrian Ratiu 2020-11-06 11:50 ` Adrian Ratiu 2020-11-06 18:01 ` Nathan Chancellor [this message] 2020-11-06 18:01 ` Nathan Chancellor 2020-11-06 19:52 ` Nick Desaulniers 2020-11-06 19:52 ` Nick Desaulniers 2020-11-07 18:07 ` Adrian Ratiu 2020-11-07 18:07 ` Adrian Ratiu 2020-11-09 19:53 ` Adrian Ratiu 2020-11-09 19:53 ` Adrian Ratiu 2020-11-10 21:41 ` Nick Desaulniers 2020-11-10 21:41 ` Nick Desaulniers 2020-11-10 22:15 ` Arvind Sankar 2020-11-10 22:15 ` Arvind Sankar 2020-11-10 22:36 ` Nick Desaulniers 2020-11-10 22:36 ` Nick Desaulniers 2020-11-10 22:39 ` Nick Desaulniers 2020-11-10 22:39 ` Nick Desaulniers 2020-11-10 22:39 ` Nick Desaulniers 2020-11-10 22:39 ` Nick Desaulniers 2020-11-10 22:54 ` Arvind Sankar 2020-11-10 22:54 ` Arvind Sankar 2020-11-10 23:56 ` Adrian Ratiu 2020-11-10 23:56 ` Adrian Ratiu 2020-11-11 0:18 ` Nick Desaulniers 2020-11-11 0:18 ` Nick Desaulniers 2020-11-11 14:15 ` Adrian Ratiu 2020-11-11 14:15 ` Adrian Ratiu 2020-11-12 21:50 ` Arvind Sankar 2020-11-12 21:50 ` Arvind Sankar 2020-11-12 21:55 ` Nick Desaulniers 2020-11-12 21:55 ` Nick Desaulniers 2020-11-07 10:22 ` Russell King - ARM Linux admin 2020-11-07 10:22 ` Russell King - ARM Linux admin 2020-11-07 18:12 ` Adrian Ratiu 2020-11-07 18:12 ` Adrian Ratiu 2020-11-08 17:40 ` Arvind Sankar 2020-11-08 17:40 ` Arvind Sankar 2020-11-08 18:09 ` Arvind Sankar 2020-11-08 18:09 ` Arvind Sankar 2020-11-08 20:14 ` Ard Biesheuvel 2020-11-08 20:14 ` Ard Biesheuvel
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=20201106180115.GB2959494@ubuntu-m3-large-x86 \ --to=natechancellor@gmail.com \ --cc=adrian.ratiu@collabora.com \ --cc=ardb@kernel.org \ --cc=arnd@arndb.de \ --cc=clang-built-linux@googlegroups.com \ --cc=kernel@collabora.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=ndesaulniers@google.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.