Support cross-compiling Halide

[shoaibkamil]

We should support cross-compiling Halide for a different architecture. Concretely, I'm trying to build Halide for arm64-windows. After more wrangling than I'd like, I've managed to get a cross-compiled LLVM for arm64-windows, following these steps:

1. Install the appropriate toolchain from the VC installer
2. Build LLVM from source using directions on the Halide webpage, but don't install. Here, I'm using LLVM 10.
3. vcpkg env --triplet arm64-windows
4. cmake -G Ninja -DCMAKE_CROSSCOMPILING=True -DCMAKE_INSTALL_PREFIX=<install-dir> -DLLVM_TABLEGEN=d:/llvm-x64-build/bin/llvm-tblgen -DCLANG_TABLEGEN=d:/llvm-x64-build/clang-tblgen -DLLVM_DEFAULT_TARGET_TRIPLE=aarch64-pc-windows-mscvc -DLLVM_TARGET=aarch64 -DENABLE_DIA_SDK=off <rest of options from halide webpage>
   Note here that enabling the DIA SDK will cause the build to fail.
5. cmake --build . --config release --target install --parallel %NUMBER_OF_PROCESSORS%
6. Build fails because it attempts to use the newly-built llvm-nm.exe for arm64. Manually edit build.ninja, search for --nm, and point it to the x64 one built earlier instead
7. cmake --build . --config release --target install --parallel %NUMBER_OF_PROCESSORS%

The build should succeed then. However, trying to build Halide:

1. cmake -G Ninja -DCMAKE_CROSSCOMPILING=True -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=d:/halide/vcpkg/scripts/buildsystems/vcpkg.cmake -DLLVM_DIR=d:/halide/llvm-arm-install/lib/cmake/llvm -DClang_DIR=d:/halide/llvm-arm-install/lib/cmake/clang -DWITH_PYTHON_BINDINGS=off ..\halide
2. cmake.exe --build . --config release --parallel 5 fails with:

[9/3549] Generating _initmod_HalidePyTorchCudaHelpers_h.cpp
FAILED: src/runtime/_initmod_HalidePyTorchCudaHelpers_h.cpp
cmd.exe /C "cd /D D:\halide\halide-arm-build\src\runtime && D:\halide\halide-arm-build\bin\binary2cpp.exe halide_internal_runtime_header_HalidePyTorchCudaHelpers_h < D:/halide/halide/src/runtime/HalidePyTorchCudaHelpers.h > _initmod_HalidePyTorchCudaHelpers_h.cpp"
This version of D:\halide\halide-arm-build\bin\binary2cpp.exe is not compatible with the version of Windows you're running. Check your computer's system information and then contact the software publisher.
[13/3549] Building CXX object apps\autoscheduler\CMakeFiles\weightsdir_to_weightsfile.dir\Weights.cpp.obj
ninja: build stopped: subcommand failed.

[shoaibkamil]

@alexreinking may have thoughts on this. I think we may need to have flags to specify the right tools to use for local bits, and to skip test_internal etc.

[abadams]

To be clear for anyone stumbling on this issue: Halide is already a functioning cross-compiler. This issue is about cross-compiling the compiler itself.

[steven-johnson]

.github/workflows/test.yml has a setup that was working for an x86 -> arm64 crosscompile, at least as of a few months ago (the CMake rewrite means it probably needs some love).

[shoaibkamil]

@steven-johnson Interesting-- that may mean that the issues I'm seeing are Windows-specific. Let me see if I can get it to work on Linux first.

[zvookin]

This is basically a matter of documentation and hammering out build system issues. I think there may be one place where we run Halide inside the build for autoscheduler stuff that may need to be carefully looked at, but other than that, it's just a set of details that need to be refined. The issue with this is that a) it depends on the build system and thus has to be updated every time that changes significantly or a new build step is added that uses new tools, and b) it inevitably has specifics for each cross compile target more so than most other platform things do.

So yes, we should do our best to enable this, but to me it feels a lot more like awareness for anyone working on build stuff, maybe a Wiki page to collect experience, and fixing bugs as they arise than a thing where we can guarantee easy and reliable cross compilation of the library itself over the long haul by design.

[alexreinking]

Yeah, CMake isn't going to make this easy because our build tools will have to be built with a different toolchain from our actual compiler. This is a scenario CMake doesn't really support. I've been thinking of ways to replace those tools with native CMake logic. If I can accomplish that, then we can just use a toolchain file to set up cross compilation and things should just work.

Otherwise, we might have to look in to separating components of our build further and creating a so-called "superbuild" structure.

[shoaibkamil]

LLVM's approach seems to separate out tools that need to run during compile-time into their own variables. I imagine we'd get pretty far if we just separated out the compilation of binary2cpp so that it uses the host toolchain.

Agree with @zvookin that this is mostly a matter of wrestling with build systems, and gathering that knowledge up somewhere.

[alexreinking]

Also +1 for the wiki page idea.

[abadams]

Relevant: I plan to add more host tools in future (e.g. to generate minimal if/else trees for the simplifier instead of using templates to metaprogram), so we should make sure the solution can grow to less trivial tools than binary2cpp and build_halide_h. I vote superbuild with a subproject to handle the host tools, but I don't know much about them so maybe that doesn't solve the issue.

[alexreinking]

That's a good reason to try that out. I'll explore that.