Okay, but what if you're using GCC's coverage implementation?
We cannot be in the business of parsing third party compiler command lines
The person controlling the build is in charge of configuring their tools. Someone set
-fsanitize=fuzzer-no-link. It's their responsibility to configure Halide as necessary, too. Just like if they were going to set CXXFLAGS or FFLAGS in the same project
Since CMake is our blessed build system and we prefer our AOT users to go through our helpers, adding a configuration point there makes the most sense to me.
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.