[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKv+Gu8nWO_GCPF1e6viGTSi5c-C+HoXqFNU=9yboC47E-kAFg@mail.gmail.com>
Date: Mon, 11 Mar 2019 17:49:21 +0100
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Nathan Chancellor <natechancellor@...il.com>,
Russell King <linux@...linux.org.uk>,
Nicolas Pitre <nicolas.pitre@...aro.org>,
Tri Vo <trong@...roid.com>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
Jonathan Corbet <corbet@....net>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: Ensure that NEON code always compiles with Clang
On Mon, 11 Mar 2019 at 17:22, Arnd Bergmann <arnd@...db.de> wrote:
>
> On Sat, Dec 15, 2018 at 10:24 PM Nathan Chancellor
> <natechancellor@...il.com> wrote:
> > endif
> > diff --git a/arch/arm/lib/xor-neon.c b/arch/arm/lib/xor-neon.c
> > index a6741a895189..4600b62d845f 100644
> > --- a/arch/arm/lib/xor-neon.c
> > +++ b/arch/arm/lib/xor-neon.c
> > @@ -14,7 +14,7 @@
> > MODULE_LICENSE("GPL");
> >
> > #ifndef __ARM_NEON__
> > -#error You should compile this file with '-mfloat-abi=softfp -mfpu=neon'
> > +#error You should compile this file with '-march=armv7-a -mfloat-abi=softfp -mfpu=neon'
> > #endif
> >
>
> I see this patch has made it in now, but I also see two other problems with the
> same file that prevent it from working right with clang:
>
> - it triggers #warning This code requires at least version 4.6 of GCC
What is currently the oldest GCC we support for ARM?
> - As I reported in https://bugs.llvm.org/show_bug.cgi?id=40976, even
> when it builds cleanly, it does not get vectorized.
>
> Has anyone actually managed to get this to do the right thing?
>
On my Cortex-A57 under KVM, I get this at boot
[ 0.002287] xor: measuring software checksum speed
[ 0.100054] arm4regs : 5212.800 MB/sec
[ 0.200131] 8regs : 3472.800 MB/sec
[ 0.300205] 32regs : 3282.000 MB/sec
[ 0.400281] neon : 7011.600 MB/sec
So that means that
a) the cost model is inaccurate, at least for some cores,
b) given that the code is only selected if it is faster, it would be
nice if we could override the cost model based decisions made by the
vectorizer.
Powered by blists - more mailing lists