I have both aarch64 and arm android standalone toolchains and any build (cpu/gpu) with aarch64 is successful however, when changing TVM_NDK_CC="/android-toolchain-arm/bin/arm-linux-androideabi-gcc" or "arm-linux-androideabi-clang" (for 32bits), with target="opencl", target_host="llvm -target=arm-linux-androideabi" or target_host="llvm -target=armv7a-linux-android"respectively, but fails with
RuntimeError: Compilation error:
/android-toolchain-arm/bin/../lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin/ld: error: /tmp/tmpc964gln3/lib.o uses VFP register arguments, output does not
collect2: error: ld returned 1 exit status
This does not seem to be a problem of TVM itself, which the developer cannot act on to fix the code to resolve this. So let us keep the discussions in the forum.
My guess is that the problem still has things to do with target triple mismatch in the target triple passed into target_host in your tvm.build. Setting that to be the exact same triple of TARGET reported by your cross-compiler might help
Sure! I checked them and updated my first post. Basically the triple with gcc is arm-linux-androideabi and with clang is armv7a-linux-android which non of then works!
Googling also pointed me to some flags with I added to ndk options like -mfloat-abi=hard which seems to solve VFP issue as OpenCL uses hard vfp but was not helpful.
I only needed to add “-mfloat-abi=soft” after the “-target=armv7a-linux-android” and the build was successful for both cpu and gpu with the correct 32bit toolchain.
hi @ehsanmok, I met the same problem as you when exporting the 32bit model lib. but when I used your suggestion of adding “-mfloat-abi=soft” the export succeeded, but the model generate color artifacts, my model is an image enhancement model. Do you meet similar problem?
No sure, actually! My guess is if you’re seeing new color artifacts that were not visible before, that could be related to numerical precision mismatch between your initial model and a complied one with TVM. I haven’t noticed a result changing behaviour though, as most of DL models are not very sensitive to numerical precision errors.