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