* Re: [PATCH] ARM: Ensure that NEON code always compiles with Clang
2018-12-15 21:23 [PATCH] ARM: Ensure that NEON code always compiles with Clang Nathan Chancellor
@ 2018-12-17 18:23 ` Nicolas Pitre
2018-12-17 19:34 ` Nathan Chancellor
2018-12-21 18:11 ` Nick Desaulniers
` (2 subsequent siblings)
3 siblings, 1 reply; 9+ messages in thread
From: Nicolas Pitre @ 2018-12-17 18:23 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Russell King, Ard Biesheuvel, Jonathan Corbet, linux-doc,
linux-arm-kernel, linux-kernel, Nick Desaulniers, Tri Vo
On Sat, 15 Dec 2018, Nathan Chancellor wrote:
> While building arm32 allyesconfig, I ran into the following errors:
>
> arch/arm/lib/xor-neon.c:17:2: error: You should compile this file with
> '-mfloat-abi=softfp -mfpu=neon'
>
> In file included from lib/raid6/neon1.c:27:
> /home/nathan/cbl/prebuilt/lib/clang/8.0.0/include/arm_neon.h:28:2:
> error: "NEON support not enabled"
>
> Building V=1 showed NEON_FLAGS getting passed along to Clang but
> __ARM_NEON__ was not getting defined. Ultimately, it boils down to Clang
> only defining __ARM_NEON__ when targeting armv7, rather than armv6k,
> which is the '-march' value for allyesconfig.
>
> From lib/Basic/Targets/ARM.cpp in the Clang source:
>
> // This only gets set when Neon instructions are actually available, unlike
> // the VFP define, hence the soft float and arch check. This is subtly
> // different from gcc, we follow the intent which was that it should be set
> // when Neon instructions are actually available.
> if ((FPU & NeonFPU) && !SoftFloat && ArchVersion >= 7) {
> Builder.defineMacro("__ARM_NEON", "1");
> Builder.defineMacro("__ARM_NEON__");
> // current AArch32 NEON implementations do not support double-precision
> // floating-point even when it is present in VFP.
> Builder.defineMacro("__ARM_NEON_FP",
> "0x" + Twine::utohexstr(HW_FP & ~HW_FP_DP));
> }
>
> Ard Biesheuvel recommended explicitly adding '-march=armv7-a' at the
> beginning of the NEON_FLAGS definitions so that __ARM_NEON__ always gets
> definined by Clang. This doesn't functionally change anything because
> that code will only run where NEON is supported, which is implicitly
> armv7.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/287
> Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Did you test that this doesn't create issues with gcc e.g. complaints
from the linker that objects have incompatible architecture
specifications or similar annoyance? This already happened in the past
but I forget the exact scenario. If you already did, or after you do
validate with gcc as well, then you may add:
Acked-by: Nicolas Pitre <nico@linaro.org>
> ---
> Documentation/arm/kernel_mode_neon.txt | 4 ++--
> arch/arm/lib/Makefile | 2 +-
> arch/arm/lib/xor-neon.c | 2 +-
> lib/raid6/Makefile | 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/arm/kernel_mode_neon.txt b/Documentation/arm/kernel_mode_neon.txt
> index 525452726d31..b9e060c5b61e 100644
> --- a/Documentation/arm/kernel_mode_neon.txt
> +++ b/Documentation/arm/kernel_mode_neon.txt
> @@ -6,7 +6,7 @@ TL;DR summary
> * Use only NEON instructions, or VFP instructions that don't rely on support
> code
> * Isolate your NEON code in a separate compilation unit, and compile it with
> - '-mfpu=neon -mfloat-abi=softfp'
> + '-march=armv7-a -mfpu=neon -mfloat-abi=softfp'
> * Put kernel_neon_begin() and kernel_neon_end() calls around the calls into your
> NEON code
> * Don't sleep in your NEON code, and be aware that it will be executed with
> @@ -87,7 +87,7 @@ instructions appearing in unexpected places if no special care is taken.
> Therefore, the recommended and only supported way of using NEON/VFP in the
> kernel is by adhering to the following rules:
> * isolate the NEON code in a separate compilation unit and compile it with
> - '-mfpu=neon -mfloat-abi=softfp';
> + '-march=armv7-a -mfpu=neon -mfloat-abi=softfp';
> * issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the calls
> into the unit containing the NEON code from a compilation unit which is *not*
> built with the GCC flag '-mfpu=neon' set.
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index ad25fd1872c7..0bff0176db2c 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -39,7 +39,7 @@ $(obj)/csumpartialcopy.o: $(obj)/csumpartialcopygeneric.S
> $(obj)/csumpartialcopyuser.o: $(obj)/csumpartialcopygeneric.S
>
> ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
> - NEON_FLAGS := -mfloat-abi=softfp -mfpu=neon
> + NEON_FLAGS := -march=armv7-a -mfloat-abi=softfp -mfpu=neon
> CFLAGS_xor-neon.o += $(NEON_FLAGS)
> obj-$(CONFIG_XOR_BLOCKS) += xor-neon.o
> 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
>
> /*
> diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
> index 2f8b61dfd9b0..bfec7c87c61e 100644
> --- a/lib/raid6/Makefile
> +++ b/lib/raid6/Makefile
> @@ -25,7 +25,7 @@ endif
> ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
> NEON_FLAGS := -ffreestanding
> ifeq ($(ARCH),arm)
> -NEON_FLAGS += -mfloat-abi=softfp -mfpu=neon
> +NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon
> endif
> CFLAGS_recov_neon_inner.o += $(NEON_FLAGS)
> ifeq ($(ARCH),arm64)
> --
> 2.20.1
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] ARM: Ensure that NEON code always compiles with Clang
2018-12-17 18:23 ` Nicolas Pitre
@ 2018-12-17 19:34 ` Nathan Chancellor
0 siblings, 0 replies; 9+ messages in thread
From: Nathan Chancellor @ 2018-12-17 19:34 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Russell King, Ard Biesheuvel, Jonathan Corbet, linux-doc,
linux-arm-kernel, linux-kernel, Nick Desaulniers, Tri Vo
On Mon, Dec 17, 2018 at 01:23:52PM -0500, Nicolas Pitre wrote:
> On Sat, 15 Dec 2018, Nathan Chancellor wrote:
>
> > While building arm32 allyesconfig, I ran into the following errors:
> >
> > arch/arm/lib/xor-neon.c:17:2: error: You should compile this file with
> > '-mfloat-abi=softfp -mfpu=neon'
> >
> > In file included from lib/raid6/neon1.c:27:
> > /home/nathan/cbl/prebuilt/lib/clang/8.0.0/include/arm_neon.h:28:2:
> > error: "NEON support not enabled"
> >
> > Building V=1 showed NEON_FLAGS getting passed along to Clang but
> > __ARM_NEON__ was not getting defined. Ultimately, it boils down to Clang
> > only defining __ARM_NEON__ when targeting armv7, rather than armv6k,
> > which is the '-march' value for allyesconfig.
> >
> > From lib/Basic/Targets/ARM.cpp in the Clang source:
> >
> > // This only gets set when Neon instructions are actually available, unlike
> > // the VFP define, hence the soft float and arch check. This is subtly
> > // different from gcc, we follow the intent which was that it should be set
> > // when Neon instructions are actually available.
> > if ((FPU & NeonFPU) && !SoftFloat && ArchVersion >= 7) {
> > Builder.defineMacro("__ARM_NEON", "1");
> > Builder.defineMacro("__ARM_NEON__");
> > // current AArch32 NEON implementations do not support double-precision
> > // floating-point even when it is present in VFP.
> > Builder.defineMacro("__ARM_NEON_FP",
> > "0x" + Twine::utohexstr(HW_FP & ~HW_FP_DP));
> > }
> >
> > Ard Biesheuvel recommended explicitly adding '-march=armv7-a' at the
> > beginning of the NEON_FLAGS definitions so that __ARM_NEON__ always gets
> > definined by Clang. This doesn't functionally change anything because
> > that code will only run where NEON is supported, which is implicitly
> > armv7.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/287
> > Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>
> Did you test that this doesn't create issues with gcc e.g. complaints
> from the linker that objects have incompatible architecture
> specifications or similar annoyance? This already happened in the past
> but I forget the exact scenario. If you already did, or after you do
> validate with gcc as well, then you may add:
>
> Acked-by: Nicolas Pitre <nico@linaro.org>
>
>
Hi Nicolas,
I was 99% sure that I checked GCC before sending this but I just did
another run to confirm and everything links successfully. We still use
binutils for assembling/linking the kernel so I assume that I would have
seen a warning from ld.bfd even with Clang.
Thank you for the review!
Nathan
>
> > ---
> > Documentation/arm/kernel_mode_neon.txt | 4 ++--
> > arch/arm/lib/Makefile | 2 +-
> > arch/arm/lib/xor-neon.c | 2 +-
> > lib/raid6/Makefile | 2 +-
> > 4 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/arm/kernel_mode_neon.txt b/Documentation/arm/kernel_mode_neon.txt
> > index 525452726d31..b9e060c5b61e 100644
> > --- a/Documentation/arm/kernel_mode_neon.txt
> > +++ b/Documentation/arm/kernel_mode_neon.txt
> > @@ -6,7 +6,7 @@ TL;DR summary
> > * Use only NEON instructions, or VFP instructions that don't rely on support
> > code
> > * Isolate your NEON code in a separate compilation unit, and compile it with
> > - '-mfpu=neon -mfloat-abi=softfp'
> > + '-march=armv7-a -mfpu=neon -mfloat-abi=softfp'
> > * Put kernel_neon_begin() and kernel_neon_end() calls around the calls into your
> > NEON code
> > * Don't sleep in your NEON code, and be aware that it will be executed with
> > @@ -87,7 +87,7 @@ instructions appearing in unexpected places if no special care is taken.
> > Therefore, the recommended and only supported way of using NEON/VFP in the
> > kernel is by adhering to the following rules:
> > * isolate the NEON code in a separate compilation unit and compile it with
> > - '-mfpu=neon -mfloat-abi=softfp';
> > + '-march=armv7-a -mfpu=neon -mfloat-abi=softfp';
> > * issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the calls
> > into the unit containing the NEON code from a compilation unit which is *not*
> > built with the GCC flag '-mfpu=neon' set.
> > diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> > index ad25fd1872c7..0bff0176db2c 100644
> > --- a/arch/arm/lib/Makefile
> > +++ b/arch/arm/lib/Makefile
> > @@ -39,7 +39,7 @@ $(obj)/csumpartialcopy.o: $(obj)/csumpartialcopygeneric.S
> > $(obj)/csumpartialcopyuser.o: $(obj)/csumpartialcopygeneric.S
> >
> > ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
> > - NEON_FLAGS := -mfloat-abi=softfp -mfpu=neon
> > + NEON_FLAGS := -march=armv7-a -mfloat-abi=softfp -mfpu=neon
> > CFLAGS_xor-neon.o += $(NEON_FLAGS)
> > obj-$(CONFIG_XOR_BLOCKS) += xor-neon.o
> > 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
> >
> > /*
> > diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
> > index 2f8b61dfd9b0..bfec7c87c61e 100644
> > --- a/lib/raid6/Makefile
> > +++ b/lib/raid6/Makefile
> > @@ -25,7 +25,7 @@ endif
> > ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
> > NEON_FLAGS := -ffreestanding
> > ifeq ($(ARCH),arm)
> > -NEON_FLAGS += -mfloat-abi=softfp -mfpu=neon
> > +NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon
> > endif
> > CFLAGS_recov_neon_inner.o += $(NEON_FLAGS)
> > ifeq ($(ARCH),arm64)
> > --
> > 2.20.1
> >
> >
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ARM: Ensure that NEON code always compiles with Clang
2018-12-15 21:23 [PATCH] ARM: Ensure that NEON code always compiles with Clang Nathan Chancellor
2018-12-17 18:23 ` Nicolas Pitre
@ 2018-12-21 18:11 ` Nick Desaulniers
2019-01-26 4:01 ` [PATCH RESEND] " Nathan Chancellor
2019-03-11 16:21 ` [PATCH] " Arnd Bergmann
3 siblings, 0 replies; 9+ messages in thread
From: Nick Desaulniers @ 2018-12-21 18:11 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Russell King, Ard Biesheuvel, Jonathan Corbet, Nicolas Pitre,
linux-doc, Linux ARM, LKML, Tri Vo
On Sat, Dec 15, 2018 at 1:23 PM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> While building arm32 allyesconfig, I ran into the following errors:
>
> arch/arm/lib/xor-neon.c:17:2: error: You should compile this file with
> '-mfloat-abi=softfp -mfpu=neon'
>
> In file included from lib/raid6/neon1.c:27:
> /home/nathan/cbl/prebuilt/lib/clang/8.0.0/include/arm_neon.h:28:2:
> error: "NEON support not enabled"
>
> Building V=1 showed NEON_FLAGS getting passed along to Clang but
> __ARM_NEON__ was not getting defined. Ultimately, it boils down to Clang
> only defining __ARM_NEON__ when targeting armv7, rather than armv6k,
> which is the '-march' value for allyesconfig.
>
> From lib/Basic/Targets/ARM.cpp in the Clang source:
>
> // This only gets set when Neon instructions are actually available, unlike
> // the VFP define, hence the soft float and arch check. This is subtly
> // different from gcc, we follow the intent which was that it should be set
> // when Neon instructions are actually available.
> if ((FPU & NeonFPU) && !SoftFloat && ArchVersion >= 7) {
> Builder.defineMacro("__ARM_NEON", "1");
> Builder.defineMacro("__ARM_NEON__");
> // current AArch32 NEON implementations do not support double-precision
> // floating-point even when it is present in VFP.
> Builder.defineMacro("__ARM_NEON_FP",
> "0x" + Twine::utohexstr(HW_FP & ~HW_FP_DP));
> }
>
> Ard Biesheuvel recommended explicitly adding '-march=armv7-a' at the
> beginning of the NEON_FLAGS definitions so that __ARM_NEON__ always gets
> definined by Clang. This doesn't functionally change anything because
> that code will only run where NEON is supported, which is implicitly
> armv7.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/287
> Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Nathan,
Thanks for sending the patch, and thanks to Ard for the suggestion.
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> ---
> Documentation/arm/kernel_mode_neon.txt | 4 ++--
> arch/arm/lib/Makefile | 2 +-
> arch/arm/lib/xor-neon.c | 2 +-
> lib/raid6/Makefile | 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/arm/kernel_mode_neon.txt b/Documentation/arm/kernel_mode_neon.txt
> index 525452726d31..b9e060c5b61e 100644
> --- a/Documentation/arm/kernel_mode_neon.txt
> +++ b/Documentation/arm/kernel_mode_neon.txt
> @@ -6,7 +6,7 @@ TL;DR summary
> * Use only NEON instructions, or VFP instructions that don't rely on support
> code
> * Isolate your NEON code in a separate compilation unit, and compile it with
> - '-mfpu=neon -mfloat-abi=softfp'
> + '-march=armv7-a -mfpu=neon -mfloat-abi=softfp'
> * Put kernel_neon_begin() and kernel_neon_end() calls around the calls into your
> NEON code
> * Don't sleep in your NEON code, and be aware that it will be executed with
> @@ -87,7 +87,7 @@ instructions appearing in unexpected places if no special care is taken.
> Therefore, the recommended and only supported way of using NEON/VFP in the
> kernel is by adhering to the following rules:
> * isolate the NEON code in a separate compilation unit and compile it with
> - '-mfpu=neon -mfloat-abi=softfp';
> + '-march=armv7-a -mfpu=neon -mfloat-abi=softfp';
> * issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the calls
> into the unit containing the NEON code from a compilation unit which is *not*
> built with the GCC flag '-mfpu=neon' set.
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index ad25fd1872c7..0bff0176db2c 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -39,7 +39,7 @@ $(obj)/csumpartialcopy.o: $(obj)/csumpartialcopygeneric.S
> $(obj)/csumpartialcopyuser.o: $(obj)/csumpartialcopygeneric.S
>
> ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
> - NEON_FLAGS := -mfloat-abi=softfp -mfpu=neon
> + NEON_FLAGS := -march=armv7-a -mfloat-abi=softfp -mfpu=neon
> CFLAGS_xor-neon.o += $(NEON_FLAGS)
> obj-$(CONFIG_XOR_BLOCKS) += xor-neon.o
> 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
>
> /*
> diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
> index 2f8b61dfd9b0..bfec7c87c61e 100644
> --- a/lib/raid6/Makefile
> +++ b/lib/raid6/Makefile
> @@ -25,7 +25,7 @@ endif
> ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
> NEON_FLAGS := -ffreestanding
> ifeq ($(ARCH),arm)
> -NEON_FLAGS += -mfloat-abi=softfp -mfpu=neon
> +NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon
> endif
> CFLAGS_recov_neon_inner.o += $(NEON_FLAGS)
> ifeq ($(ARCH),arm64)
> --
> 2.20.1
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply [flat|nested] 9+ messages in thread* [PATCH RESEND] ARM: Ensure that NEON code always compiles with Clang
2018-12-15 21:23 [PATCH] ARM: Ensure that NEON code always compiles with Clang Nathan Chancellor
2018-12-17 18:23 ` Nicolas Pitre
2018-12-21 18:11 ` Nick Desaulniers
@ 2019-01-26 4:01 ` Nathan Chancellor
2019-01-26 16:48 ` Stefan Agner
2019-03-11 16:21 ` [PATCH] " Arnd Bergmann
3 siblings, 1 reply; 9+ messages in thread
From: Nathan Chancellor @ 2019-01-26 4:01 UTC (permalink / raw)
To: Russell King, Ard Biesheuvel, Jonathan Corbet
Cc: linux-doc, linux-arm-kernel, linux-kernel, Tri Vo, Stefan Agner,
Nicolas Pitre, Nick Desaulniers, Nathan Chancellor,
Nicolas Pitre
While building arm32 allyesconfig, I ran into the following errors:
arch/arm/lib/xor-neon.c:17:2: error: You should compile this file with
'-mfloat-abi=softfp -mfpu=neon'
In file included from lib/raid6/neon1.c:27:
/home/nathan/cbl/prebuilt/lib/clang/8.0.0/include/arm_neon.h:28:2:
error: "NEON support not enabled"
Building V=1 showed NEON_FLAGS getting passed along to Clang but
__ARM_NEON__ was not getting defined. Ultimately, it boils down to Clang
only defining __ARM_NEON__ when targeting armv7, rather than armv6k,
which is the '-march' value for allyesconfig.
>From lib/Basic/Targets/ARM.cpp in the Clang source:
// This only gets set when Neon instructions are actually available, unlike
// the VFP define, hence the soft float and arch check. This is subtly
// different from gcc, we follow the intent which was that it should be set
// when Neon instructions are actually available.
if ((FPU & NeonFPU) && !SoftFloat && ArchVersion >= 7) {
Builder.defineMacro("__ARM_NEON", "1");
Builder.defineMacro("__ARM_NEON__");
// current AArch32 NEON implementations do not support double-precision
// floating-point even when it is present in VFP.
Builder.defineMacro("__ARM_NEON_FP",
"0x" + Twine::utohexstr(HW_FP & ~HW_FP_DP));
}
Ard Biesheuvel recommended explicitly adding '-march=armv7-a' at the
beginning of the NEON_FLAGS definitions so that __ARM_NEON__ always gets
definined by Clang. This doesn't functionally change anything because
that code will only run where NEON is supported, which is implicitly
armv7.
Link: https://github.com/ClangBuiltLinux/linux/issues/287
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
---
Resending with Nicolas's ack and Nick's review, to give others a chance
to pitch in with review/testing before submitting it to the patch
system (specifically Stefan, sorry I should have included you in the
previous posting).
With this patch and:
* A tip of tree LLVM build (I used apt.llvm.org)
* Clang GCOV support: https://lore.kernel.org/lkml/20190122233749.42220-1-trong@android.com/
* Two minor hacks for unrelated issues that are still being worked through:
* https://raw.githubusercontent.com/nathanchance/patches/c313b2fa0efb/linux/build-hax/0003-DO-NOT-UPSTREAM-ARM-Don-t-select-HAVE_FUNCTION_TRACE.patch (see https://github.com/ClangBuiltLinux/linux/issues/35)
* https://gist.githubusercontent.com/nathanchance/b2f5a4015abade1a41e78d5fc3235c5b/raw/744321882ab05511331f26896bad7c9f0056a6a5/gistfile1.txt (see https://github.com/ClangBuiltLinux/linux/issues/325)
I can build and link a little endian allyesconfig ARM kernel. This
patch alone works with GCC 8.2.0 and binutils 2.31.1.
Documentation/arm/kernel_mode_neon.txt | 4 ++--
arch/arm/lib/Makefile | 2 +-
arch/arm/lib/xor-neon.c | 2 +-
lib/raid6/Makefile | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/arm/kernel_mode_neon.txt b/Documentation/arm/kernel_mode_neon.txt
index 525452726d31..b9e060c5b61e 100644
--- a/Documentation/arm/kernel_mode_neon.txt
+++ b/Documentation/arm/kernel_mode_neon.txt
@@ -6,7 +6,7 @@ TL;DR summary
* Use only NEON instructions, or VFP instructions that don't rely on support
code
* Isolate your NEON code in a separate compilation unit, and compile it with
- '-mfpu=neon -mfloat-abi=softfp'
+ '-march=armv7-a -mfpu=neon -mfloat-abi=softfp'
* Put kernel_neon_begin() and kernel_neon_end() calls around the calls into your
NEON code
* Don't sleep in your NEON code, and be aware that it will be executed with
@@ -87,7 +87,7 @@ instructions appearing in unexpected places if no special care is taken.
Therefore, the recommended and only supported way of using NEON/VFP in the
kernel is by adhering to the following rules:
* isolate the NEON code in a separate compilation unit and compile it with
- '-mfpu=neon -mfloat-abi=softfp';
+ '-march=armv7-a -mfpu=neon -mfloat-abi=softfp';
* issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the calls
into the unit containing the NEON code from a compilation unit which is *not*
built with the GCC flag '-mfpu=neon' set.
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index ad25fd1872c7..0bff0176db2c 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -39,7 +39,7 @@ $(obj)/csumpartialcopy.o: $(obj)/csumpartialcopygeneric.S
$(obj)/csumpartialcopyuser.o: $(obj)/csumpartialcopygeneric.S
ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
- NEON_FLAGS := -mfloat-abi=softfp -mfpu=neon
+ NEON_FLAGS := -march=armv7-a -mfloat-abi=softfp -mfpu=neon
CFLAGS_xor-neon.o += $(NEON_FLAGS)
obj-$(CONFIG_XOR_BLOCKS) += xor-neon.o
endif
diff --git a/arch/arm/lib/xor-neon.c b/arch/arm/lib/xor-neon.c
index 2c40aeab3eaa..c691b901092f 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
/*
diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
index 4e90d443d1b0..e723eacf7868 100644
--- a/lib/raid6/Makefile
+++ b/lib/raid6/Makefile
@@ -39,7 +39,7 @@ endif
ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
NEON_FLAGS := -ffreestanding
ifeq ($(ARCH),arm)
-NEON_FLAGS += -mfloat-abi=softfp -mfpu=neon
+NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon
endif
CFLAGS_recov_neon_inner.o += $(NEON_FLAGS)
ifeq ($(ARCH),arm64)
--
2.20.1
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH RESEND] ARM: Ensure that NEON code always compiles with Clang
2019-01-26 4:01 ` [PATCH RESEND] " Nathan Chancellor
@ 2019-01-26 16:48 ` Stefan Agner
0 siblings, 0 replies; 9+ messages in thread
From: Stefan Agner @ 2019-01-26 16:48 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Russell King, Ard Biesheuvel, Jonathan Corbet, linux-doc,
linux-arm-kernel, linux-kernel, Tri Vo, Nicolas Pitre,
Nick Desaulniers, Nicolas Pitre
On 26.01.2019 05:01, Nathan Chancellor wrote:
> While building arm32 allyesconfig, I ran into the following errors:
>
> arch/arm/lib/xor-neon.c:17:2: error: You should compile this file with
> '-mfloat-abi=softfp -mfpu=neon'
>
> In file included from lib/raid6/neon1.c:27:
> /home/nathan/cbl/prebuilt/lib/clang/8.0.0/include/arm_neon.h:28:2:
> error: "NEON support not enabled"
>
> Building V=1 showed NEON_FLAGS getting passed along to Clang but
> __ARM_NEON__ was not getting defined. Ultimately, it boils down to Clang
> only defining __ARM_NEON__ when targeting armv7, rather than armv6k,
> which is the '-march' value for allyesconfig.
>
>>From lib/Basic/Targets/ARM.cpp in the Clang source:
>
> // This only gets set when Neon instructions are actually available, unlike
> // the VFP define, hence the soft float and arch check. This is subtly
> // different from gcc, we follow the intent which was that it should be set
> // when Neon instructions are actually available.
> if ((FPU & NeonFPU) && !SoftFloat && ArchVersion >= 7) {
> Builder.defineMacro("__ARM_NEON", "1");
> Builder.defineMacro("__ARM_NEON__");
> // current AArch32 NEON implementations do not support double-precision
> // floating-point even when it is present in VFP.
> Builder.defineMacro("__ARM_NEON_FP",
> "0x" + Twine::utohexstr(HW_FP & ~HW_FP_DP));
> }
>
> Ard Biesheuvel recommended explicitly adding '-march=armv7-a' at the
> beginning of the NEON_FLAGS definitions so that __ARM_NEON__ always gets
> definined by Clang. This doesn't functionally change anything because
> that code will only run where NEON is supported, which is implicitly
> armv7.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/287
> Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> Acked-by: Nicolas Pitre <nico@linaro.org>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> ---
>
> Resending with Nicolas's ack and Nick's review, to give others a chance
> to pitch in with review/testing before submitting it to the patch
> system (specifically Stefan, sorry I should have included you in the
> previous posting).
No worries.
Looks good to me.
Reviewed-by: Stefan Agner <stefan@agner.ch>
--
Stefan
>
> With this patch and:
> * A tip of tree LLVM build (I used apt.llvm.org)
> * Clang GCOV support:
> https://lore.kernel.org/lkml/20190122233749.42220-1-trong@android.com/
> * Two minor hacks for unrelated issues that are still being worked through:
> *
> https://raw.githubusercontent.com/nathanchance/patches/c313b2fa0efb/linux/build-hax/0003-DO-NOT-UPSTREAM-ARM-Don-t-select-HAVE_FUNCTION_TRACE.patch
> (see https://github.com/ClangBuiltLinux/linux/issues/35)
> *
> https://gist.githubusercontent.com/nathanchance/b2f5a4015abade1a41e78d5fc3235c5b/raw/744321882ab05511331f26896bad7c9f0056a6a5/gistfile1.txt
> (see https://github.com/ClangBuiltLinux/linux/issues/325)
>
> I can build and link a little endian allyesconfig ARM kernel. This
> patch alone works with GCC 8.2.0 and binutils 2.31.1.
>
> Documentation/arm/kernel_mode_neon.txt | 4 ++--
> arch/arm/lib/Makefile | 2 +-
> arch/arm/lib/xor-neon.c | 2 +-
> lib/raid6/Makefile | 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/arm/kernel_mode_neon.txt
> b/Documentation/arm/kernel_mode_neon.txt
> index 525452726d31..b9e060c5b61e 100644
> --- a/Documentation/arm/kernel_mode_neon.txt
> +++ b/Documentation/arm/kernel_mode_neon.txt
> @@ -6,7 +6,7 @@ TL;DR summary
> * Use only NEON instructions, or VFP instructions that don't rely on support
> code
> * Isolate your NEON code in a separate compilation unit, and compile it with
> - '-mfpu=neon -mfloat-abi=softfp'
> + '-march=armv7-a -mfpu=neon -mfloat-abi=softfp'
> * Put kernel_neon_begin() and kernel_neon_end() calls around the
> calls into your
> NEON code
> * Don't sleep in your NEON code, and be aware that it will be executed with
> @@ -87,7 +87,7 @@ instructions appearing in unexpected places if no
> special care is taken.
> Therefore, the recommended and only supported way of using NEON/VFP in the
> kernel is by adhering to the following rules:
> * isolate the NEON code in a separate compilation unit and compile it with
> - '-mfpu=neon -mfloat-abi=softfp';
> + '-march=armv7-a -mfpu=neon -mfloat-abi=softfp';
> * issue the calls to kernel_neon_begin(), kernel_neon_end() as well
> as the calls
> into the unit containing the NEON code from a compilation unit which is *not*
> built with the GCC flag '-mfpu=neon' set.
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index ad25fd1872c7..0bff0176db2c 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -39,7 +39,7 @@ $(obj)/csumpartialcopy.o: $(obj)/csumpartialcopygeneric.S
> $(obj)/csumpartialcopyuser.o: $(obj)/csumpartialcopygeneric.S
>
> ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
> - NEON_FLAGS := -mfloat-abi=softfp -mfpu=neon
> + NEON_FLAGS := -march=armv7-a -mfloat-abi=softfp -mfpu=neon
> CFLAGS_xor-neon.o += $(NEON_FLAGS)
> obj-$(CONFIG_XOR_BLOCKS) += xor-neon.o
> endif
> diff --git a/arch/arm/lib/xor-neon.c b/arch/arm/lib/xor-neon.c
> index 2c40aeab3eaa..c691b901092f 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
>
> /*
> diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
> index 4e90d443d1b0..e723eacf7868 100644
> --- a/lib/raid6/Makefile
> +++ b/lib/raid6/Makefile
> @@ -39,7 +39,7 @@ endif
> ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
> NEON_FLAGS := -ffreestanding
> ifeq ($(ARCH),arm)
> -NEON_FLAGS += -mfloat-abi=softfp -mfpu=neon
> +NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon
> endif
> CFLAGS_recov_neon_inner.o += $(NEON_FLAGS)
> ifeq ($(ARCH),arm64)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ARM: Ensure that NEON code always compiles with Clang
2018-12-15 21:23 [PATCH] ARM: Ensure that NEON code always compiles with Clang Nathan Chancellor
` (2 preceding siblings ...)
2019-01-26 4:01 ` [PATCH RESEND] " Nathan Chancellor
@ 2019-03-11 16:21 ` Arnd Bergmann
2019-03-11 16:49 ` Ard Biesheuvel
3 siblings, 1 reply; 9+ messages in thread
From: Arnd Bergmann @ 2019-03-11 16:21 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Russell King, Ard Biesheuvel, Nicolas Pitre, Tri Vo,
open list:DOCUMENTATION, Jonathan Corbet, Nick Desaulniers,
Linux Kernel Mailing List, Linux ARM
On Sat, Dec 15, 2018 at 10:24 PM Nathan Chancellor
<natechancellor@gmail.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
- 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?
Arnd
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] ARM: Ensure that NEON code always compiles with Clang
2019-03-11 16:21 ` [PATCH] " Arnd Bergmann
@ 2019-03-11 16:49 ` Ard Biesheuvel
2019-03-11 21:36 ` Arnd Bergmann
0 siblings, 1 reply; 9+ messages in thread
From: Ard Biesheuvel @ 2019-03-11 16:49 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Nathan Chancellor, Russell King, Nicolas Pitre, Tri Vo,
open list:DOCUMENTATION, Jonathan Corbet, Nick Desaulniers,
Linux Kernel Mailing List, Linux ARM
On Mon, 11 Mar 2019 at 17:22, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Sat, Dec 15, 2018 at 10:24 PM Nathan Chancellor
> <natechancellor@gmail.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.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] ARM: Ensure that NEON code always compiles with Clang
2019-03-11 16:49 ` Ard Biesheuvel
@ 2019-03-11 21:36 ` Arnd Bergmann
0 siblings, 0 replies; 9+ messages in thread
From: Arnd Bergmann @ 2019-03-11 21:36 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Nathan Chancellor, Russell King, Nicolas Pitre, Tri Vo,
open list:DOCUMENTATION, Jonathan Corbet, Nick Desaulniers,
Linux Kernel Mailing List, Linux ARM
On Mon, Mar 11, 2019 at 5:49 PM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> On Mon, 11 Mar 2019 at 17:22, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Sat, Dec 15, 2018 at 10:24 PM Nathan Chancellor
> > <natechancellor@gmail.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?
Linux overall requires gcc-4.6, so we could just as well drop this
check, good point.
Arnd
^ permalink raw reply [flat|nested] 9+ messages in thread