arm64 code compilation on x86 apple host
Hi,
Here https://github.com/ARM-software/ComputeLibrary/issues/994 we are discussing an issue that ARM compute library cannot be cross-compiled from Apple X86 host using the compiler from Xcode 12.2. Such compiler is able to compile both x86 and arm64 code and it's controlled via -arch option. So, cmake is able to do this and has CMAKE_OSX_ARCHITECTURES option which is mapped to -arch flags.
But when we are trying to do the same using scons build system, we see issue (logs from OSX 12 with x86 underneath):
2022-09-04T21:38:14.8309740Z create_version_file(["/Users/runner/work/1/_w/build/build-modules/arm_plugin/thirdparty/src/core/arm_compute_version.embed"], [])
2022-09-04T21:38:14.8318320Z ccache clang++ -o /Users/runner/work/1/_w/build/build-modules/arm_plugin/thirdparty/src/common/cpuinfo/CpuInfo.o -c -DARCH_ARM -Wextra -Wdisabled-optimization -Wformat=2 -Winit-self -Wstrict-overflow=2 -Wswitch-default -Woverloaded-virtual -Wformat-security -Wctor-dtor-privacy -Wsign-promo -Weffc++ -Wno-overlength-strings -Wall -std=c++14 -pedantic -Wno-vla-extension -march=armv8.6-a -DENABLE_FP16_KERNELS -DENABLE_FP32_KERNELS -DENABLE_QASYMM8_KERNELS -DENABLE_QASYMM8_SIGNED_KERNELS -DENABLE_QSYMM16_KERNELS -DENABLE_INTEGER_KERNELS -DENABLE_NCHW_KERNELS -O3 -fPIC -fsigned-char -ffunction-sections -fdata-sections -fdiagnostics-show-option -Wundef -Wreturn-type -Wunused-variable -Wswitch -Wno-error=deprecated-declarations -Wno-undef -Wno-error=return-stack-address -D_GLIBCXX_USE_NANOSLEEP -DARM_COMPUTE_CPP_SCHEDULER=1 -DENABLE_NEON -DARM_COMPUTE_ENABLE_NEON -DARM_COMPUTE_ENABLE_I8MM -DARM_COMPUTE_ENABLE_BF16 -DARM_COMPUTE_ENABLE_FP16 -DARM_COMPUTE_ENABLE_SVEF32MM -DARM_COMPUTE_GRAPH_ENABLED -DARM_COMPUTE_CPU_ENABLED -DARM_COMPUTE_VERSION_MAJOR=28 -DARM_COMPUTE_VERSION_MINOR=0 -DARM_COMPUTE_VERSION_PATCH=0 -Iinclude -I. -I/Users/runner/work/1/_w/build/build-modules/arm_plugin/thirdparty/src/core -Isrc/core -I/Users/runner/work/1/_w/build/build-modules/arm_plugin/thirdparty/src/core/NEON/kernels/convolution/common -Isrc/core/NEON/kernels/convolution/common -I/Users/runner/work/1/_w/build/build-modules/arm_plugin/thirdparty/src/core/NEON/kernels/convolution/winograd -Isrc/core/NEON/kernels/convolution/winograd -I/Users/runner/work/1/_w/build/build-modules/arm_plugin/thirdparty/src/core/NEON/kernels/arm_conv/depthwise -Isrc/core/NEON/kernels/arm_conv/depthwise -I/Users/runner/work/1/_w/build/build-modules/arm_plugin/thirdparty/src/core/NEON/kernels/arm_conv/pooling -Isrc/core/NEON/kernels/arm_conv/pooling -I/Users/runner/work/1/_w/build/build-modules/arm_plugin/thirdparty/src/core/NEON/kernels/arm_conv -Isrc/core/NEON/kernels/arm_conv -I/Users/runner/work/1/_w/build/build-modules/arm_plugin/thirdparty/src/core/NEON/kernels/assembly -Isrc/core/NEON/kernels/assembly -I/Users/runner/work/1/_w/build/build-modules/arm_plugin/thirdparty/arm_compute/core/NEON/kernels/assembly -Iarm_compute/core/NEON/kernels/assembly -I/Users/runner/work/1/_w/build/build-modules/arm_plugin/thirdparty/src/cpu/kernels/assembly -Isrc/cpu/kernels/assembly src/common/cpuinfo/CpuInfo.cpp
2022-09-04T21:38:14.8326460Z error: unknown target CPU 'armv8.6-a'
2022-09-04T21:38:14.8329760Z note: valid target CPU values are: nocona, core2, penryn, bonnell, atom, silvermont, slm, goldmont, goldmont-plus, tremont, nehalem, corei7, westmere, sandybridge, corei7-avx, ivybridge, core-avx-i, haswell, core-avx2, broadwell, skylake, skylake-avx512, skx, cascadelake, cooperlake, cannonlake, icelake-client, icelake-server, tigerlake, sapphirerapids, alderlake, knl, knm, k8, athlon64, athlon-fx, opteron, k8-sse3, athlon64-sse3, opteron-sse3, amdfam10, barcelona, btver1, btver2, bdver1, bdver2, bdver3, bdver4, znver1, znver2, znver3, x86-64, x86-64-v2, x86-64-v3, x86-64-v4
2022-09-04T21:38:14.8332610Z scons: *** [/Users/runner/work/1/_w/build/build-modules/arm_plugin/thirdparty/src/common/cpuinfo/CpuInfo.o] Error 1
2022-09-04T21:38:14.8333940Z scons: building terminated because of errors.
Specifically, error: unknown target CPU 'armv8.6-a'. But why? I suppose this message comes from internals of scons which is not able to understand that on Apple host we can compile both instruction sets.
Am I right that it's a bug / limitation of scons?
The message is not from scons itself, but it's also not clear that scons would know what to do with a TARGET_ARCH set to something other than the host. See the comments here - basically this is implemented/debugged only for msvc at this point:
https://scons.org/doc/production/HTML/scons-man.html#cv-TARGET_ARCH
So you'd end up responsible for setting the right flags.
Okay, I looked at the referenced issue briefly - there's nothing that will automatically point scons at a cross-build toolchain, so you need to do that yourself. We can answer questions on that (you might want to hop onto the discord server for a bit more interactive experience), but this may also be of help:
https://scons-cookbook.readthedocs.io/en/latest/#setting-up-a-cross-compile-environment
Why should I set something when host compiler == cross compiler?
The message is not from scons itself
but who is the source of the message? I've grepped over ARM compute and there is no such messages
scons would know what to do with a TARGET_ARCH set to something other than the host
Why? During usual cross-compilation on x86 Linux for arm64 we have host arch = 86, while TARGET_ARCH = arm64.
there's nothing that will automatically point scons at a cross-build toolchain
scons must detect xcode version and allow both arm and x86 architectures if xcode version >= 12.2
I perfectly understand how cross-compilation works, but I still don't understand who is a guilty - scons or arm compute scripts.
Have you even try to cross-compile from apple x86 for apple arm with scons?
@ilya-lavrenov - the message is not from SCons.
There is currently no built in logic for cross compiling for any toolchain other than MSVC.
Try running clang++ --print-supported-cpus on your builder system.
It's likely you'll see it does not support armv8.6-a
I don't have access to an intel mac with xcode 12.2. So therefore am unable to try this out.
I'm not sure why you think "scons must" anything. This is an open source project supported by volunteers. People will contribute new features, bug fixes, etc based on those things they themselves are interested in.
If you'd like to help SCons add functionality which is useful to you, we welcome those efforts.
I don't use a Mac at all, so probably need to leave a lot of this to someone else. One of the messages in the issue you pointed to suggested that the clang being used didn't understand the target you were trying to give it (and that that is the source of the error message), if so you need the syntax suggested, to point to the correct toolchain - or else scons' auto-detection of tools will defeat you. If that's not the case, then ignore that part.
The scons construction variable TARGET_ARCH could be used to set variables in the platform code (the Mac platform is named 'darwin' in SCons), but it does not do that, thus my claim you'd have to set that yourself.
SCons doesn't know anything about xcode, it only deals at the compiler level here. It does ask clang for the version, but there's no cross-compile logic in the tool.
Workarounded via cross-compilation https://github.com/openvinotoolkit/openvino_contrib/pull/438
Workarounded via cross-compilation openvinotoolkit/openvino_contrib#438
I looked at the patch on the linked PR, can you explain what you did so perhaps we can enhance SCons?