Yes, I think so. We are not clang based, we are LLVM based. If you want, you can build Halide and your generator executables on Windows, using MSVC, and produce binaries for Linux that are compatible with the toolchains there.
We use any C++ compiler and package the compiler as a library into the resulting application. LLVM is linked in,, too.. You run that program, which produces an AST at execution time, which is passed either to MCJIT or to the usual LLVM pipeline to produce (essentially) an object file and header pair
This is to say that we are staged in C++ rather than being a subset of C++
Having the full power of C++ to metaprogram Halide and being able to piggyback off its tooling are major boons to Halide
(but maybe i just didn't find it yet)
So we maintain ABI stability within a major version, only add APIs within minor versions, and change neither within patch versions
The
master branch has no guarantees at all
And we branch off of
master to release new major versions.
If we do it as a string pass through, it’s pretty easy to implement. Part if the idea of Target was to provide a better API to configuring the backend. So commonly used things may still get surfaced there, but there is no way we’re going to put all of LLVM’s flags in Target.
There is also the issue of being able to pass in string arguments that conflict with something Halide is passing to LLVM via e.g. mcpu or mattrs.
Hopefully this helps but the tl;dr is the feature doesn’t exist yet but we should add it.
Where “we” means anyone is welcome to take a crack at doing so :-)
Can be used as a hack, but not good for anything production.
If it is a change in the instruction set, it probably needs a feature flag.
There’s another wrinkle…
I don’t know if znver3 is a change in the ISA or just performance
And the automatic choice implementation depends on it being a bit set.
I think features should drive a default choice of mcpu. If one wants a different choice, it is required that it be compatible with the features.
Changes in the instruction set itself — like new opcodes etc., probably should be features
We could add a utility library that constructs the right features from some input such as the name for the processor or a serialized form of its CPUID stuff or some string obtained from /proc etc.
Using LLVM’s means of specifying this stuff as our means if doing it is a huge nonstarter for a variety of reasons.
Some of that has to run at runtime and cannot require LLVM. In general, Halide is not supposed to require LLVM unless one is using an LLVM based backend. That doesn’t quite work yet, but there is some work going toward it.
Simply because LLVM is not the right tool for all jobs.