On Sat, Oct 31, 2020 at 09:34:07PM +0100, Alexander Strasser wrote:

On 2020-08-30 18:27 +0300, reimar wrote:

...

Author: reimar Date: Sun Aug 30 18:27:41 2020 New Revision: 38194

Log: configure: Fix arm CPU extension selection

If runtime cpudetection is off, we need to set all of march, mcpu and mfpu. Otherwise compiling on e.g. Rasbian will result in a build with no NEON support even when the CPU supports it.

Modified: trunk/configure

Modified: trunk/configure ============================================================================== --- trunk/configure Sat Aug 22 00:13:38 2020 (r38193) +++ trunk/configure Sun Aug 30 18:27:41 2020 (r38194) @@ -2478,6 +2478,9 @@ case "$host_arch" in aarch64) arch='aarch64' iproc='aarch64' + if test "$_runtime_cpudetection" = no ; then + cflag_check -march=native -mcpu=native -mfpu=auto && _march="-march=native -mcpu=native -mfpu=auto" + fi ;;

arm*) @@ -2487,6 +2490,9 @@ case "$host_arch" in def_av_fast_unaligned='#define AV_HAVE_FAST_UNALIGNED 1' def_local_aligned='#define HAVE_LOCAL_ALIGNED 1' test $_fast_clz = "auto" && _fast_clz=yes + if test "$_runtime_cpudetection" = no ; then + cflag_check -march=native -mcpu=native -mfpu=auto && _march="-march=native -mcpu=native -mfpu=auto" + fi ;;

avr32) @@ -9416,8 +9422,11 @@ $def_openssl #define CONFIG_VAAPI 0

#define HAVE_ALIGNED_STACK 1

...

+#define HAVE_AS_ARCH_DIRECTIVE 1 #define HAVE_AS_DN_DIRECTIVE 1 +#define HAVE_AS_FPU_DIRECTIVE 1 #define HAVE_AS_FUNC 1 +#define HAVE_AS_OBJECT_ARCH 1

These changes seem a bit underrepresented in the commit message.

Are they necessary for a good and optimized ARM build?

When NEON is enabled they seem to be necessary full stop. I got various compilation errors in FFmpeg without them. It's possible they increase the build environment requirements for systems without NEON, but it feels like the case of ARM CPU without NEON + weird/heavily outdated toolchain is something we can handle when it comes up.