Failure to detect CPU type for Apple Silicon

[fxcoudert]

On Apple ARM64, the makefile does not recognise the CPU type:

$ make CC=clang FC=gfortran all                                
Makefile:154: *** OpenBLAS: Detecting CPU failed. Please set TARGET explicitly, e.g. make TARGET=your_cpu_target. Please read README for the detail..  Stop.

The configuration detection stuff involves a lot of different files, but maybe it's because all the stuff in cpuid_arm64.c is Linux-specific.

Passing TARGET=ARMV8 allows the build to proceed.

[fxcoudert]

Using cmake also fails. Using cmake -DTARGET=ARMV8, weirdly, still fails because it's not picking up that I have a 64-bit target:

$ cmake .. -DTARGET=ARMV8
-- The C compiler identification is AppleClang 12.0.0.12000031
-- The ASM compiler identification is Clang
-- Found assembler: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
CMake Warning at CMakeLists.txt:66 (message):
  CMake support is experimental.  It does not yet support all build options
  and may not produce the same Makefiles that OpenBLAS ships with.


-- Compiling a 32-bit binary.
-- Targeting the ARMV7 architecture.
-- GEMM multithread threshold set to 4.
-- Disabling Advanced Vector Extensions (AVX).
-- Multi-threading enabled with 8 threads.
-- The Fortran compiler identification is GNU 11.0.0
-- Checking whether Fortran compiler has -isysroot
-- Checking whether Fortran compiler has -isysroot - yes
-- Checking whether Fortran compiler supports OSX deployment target flag
-- Checking whether Fortran compiler supports OSX deployment target flag - yes
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Check for working Fortran compiler: /Users/fx/irun/bin/gfortran - skipped
-- Checking whether /Users/fx/irun/bin/gfortran supports Fortran 90
-- Checking whether /Users/fx/irun/bin/gfortran supports Fortran 90 - yes
-- Running getarch
-- GETARCH results:
CORE=ARMV7
LIBCORE=armv7
NUM_CORES=8
MAKE += -j 8

-- Compiling a 32-bit binary.
-- Building Single Precision
-- Building Double Precision
-- Building Complex Precision
-- Building Double Complex Precision
-- Reading vars from /Users/fx/OpenBLAS-0.3.10/kernel/arm/KERNEL...
-- Reading vars from /Users/fx/OpenBLAS-0.3.10/kernel/arm/KERNEL.ARMV7...
-- Reading vars from /Users/fx/OpenBLAS-0.3.10/kernel/arm/KERNEL.ARMV6...
-- Reading vars from /Users/fx/OpenBLAS-0.3.10/kernel/arm/KERNEL.ARMV5...
-- Building deprecated routines
-- Building Single Precision
-- Building Double Precision
-- Building Complex Precision
-- Building Double Complex Precision
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE  
-- Generating openblas_config.h in include/openblas
-- Generating f77blas.h in include/openblas
-- Generating cblas.h in include/openblas
-- Copying LAPACKE header files to include/openblas
-- Found PkgConfig: /usr/local/bin/pkg-config (found version "0.29.2") 
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/fx/OpenBLAS-0.3.10/build

[martin-frbg]

With CMAKE, OpenBLAS tries to use CMAKE variables - if CMAKE_SYSTEM_PROCESSOR matches aarch64, CMAKE_SIZEOF_VOID_P is used to distinguish between ARM (4) and ARM64 (8) in cmake/system_check.cmake.
I do not think it could get the size test wrong, but perhaps your system gets reported as arm-something instead of aarch.. ?
The code in cpuid_arm64.c indeed relies on reading /proc/cpuinfo - do you know if Apple supports HWCAP_CPUID as it is currently used for runtime cpu detection in DYNAMIC_ARCH builds by driver/others/dynamic_arm64.c (#2715 nonwithstanding) ?

[fxcoudert]

I think HWCAP_CPUID is linux-only.

[isuruf]

On macOS, they use arm64 instead of aarch64 for uname -m which is what CMake uses to fill CMAKE_SYSTEM_PROCESSOR

[martin-frbg]

Some days I hate it here 😄
Probably safe to assume (for now) that anything Apple that turns up with an ARM64 processor should be handled as generic ARMV8 without detailed inspection (?) Are these Silicon things out in the wild already, or is yours a special gift ?

[isuruf]

Probably safe to assume (for now) that anything Apple that turns up with an ARM64 processor should be handled as generic ARMV8 without detailed inspection

Yes.

Are these Silicon things out in the wild already, or is yours a special gift ?

They have a "Developer Transition Kit" that they rent out for $500 until the arm64 macs come out. I don't have one, but @fxcoudert probably does.

[isuruf]

The chip they ship on "Developer Transition Kit" (DTK) is a repurposed iPad chip https://en.wikipedia.org/wiki/Apple_A12Z which is ARMv8.3-A. That probably means that the arm64 macs will use the same instruction set or a newer one.

[martin-frbg]

The only cpu we actively treat as v8.3-a is ThunderX3. Wonder if anything could go wrong when we treat it as that ? (ARMV8 would obviously be safer)

[fxcoudert]

ARMV8 seems safe for the moment, indeed.

[martin-frbg]

Then #2807 should hopefully fix both these problems