The C++ backend needs a better solution for Halide runtime

[steven-johnson]

At present, if you want to use the C++ backend in real code, you don't have a good solution for the Halide runtime:

• the "normal" Halide runtime will link and work properly with this backend, but if you are using the C++ backend it may be because you have an unusual target that isn't supported well (or at all) by LLVM (e.g., an OS or architecture with bespoke compilers), so this may not be an option.
• write your own runtime stubs based on what you need. This can be error prone and is a big barrier to experimentation on such systems.

Surely we can do better. Random thoughts:

• Provide a "bare-bones" plain-posix C++ runtime example that can serve as a decent starting point for new platforms (with the assumption that it will be customized).
• Provide a way to selectively embed the existing runtime C++ source code in our C++ output. We already do this for some inlined stuff, eg HalideRuntime.h, buffer accessors, so maybe we could do it for arbitrary runtime code as well?

[abadams]

The runtime is already dependency free, so I think you can just use the source. You'd have to replicate the logic in LLVM_Runtime_Linker.cpp to pick and choose a suitable set of source files to pass to the custom toolchain. This could be done once for the target in question though.

[zvookin]

Yeah the first solution is just to copy source code from the runtime folder. The same options we support for object files should be there -- e.g. generating without runtime and the ability to use GenGen or whatever to make a runtime only file for a given target setup. The logic for selecting modules to go into the runtime will need to be abstracted to choose either the bitcode or the source code and we'll need to add the C++ source code the library as blobs. Undoubtedly there will be some source code changes needed for some platforms.

Further out, we need better features to control customizing a runtime, such as specifying which modules or routines one wants Halide to provide and likely qualifying the runtime with a user provided prefix. We also need to solve the dynamic override of runtime routines, e.g. for JIT, but that is perhaps better seen as orthogonal.