"Coverage" is kind of a weird metric for a language like Halide, though. Programs aren't very divergent. I would guess that for a "typical" pipeline, nearly every input would produce the same coverage profile.
Like, maybe you can do some weird things with RDom::where. External stages need to be instrumented separately, anyway.
Sure. I think that's a good enough reason
Yeah, we have m/t/asan feature flags
I was surprised when you said there was no msan support... I should have checked.
Halide compiled with a sanitizer doesn't need to always produce binaries with that sanitizer
And vice versa...
?
e.g. when compiling halide/apps
Clang doesn't read the CFLAGS env var AFAIK. CMake and Makefile default rules honor that variable when constructing compiler command lines.
I could see introducing Halide_TARGET_FEATURES as a CMake (package) variable to allow a user to add some features globally (through
add_halide_library)
1 reply
-DHalide_TARGET_FEATURES=msan at the command line or set() it in a toolchain file
The sanitizers are toolchain-y anyway... that approach makes sense to me
We should probably use some custom target properties for this... hmm. To-do.
the problem with sanitizer coverage is this line: https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/BackendUtil.cpp#L1156
unless halide could directly consume CFLAGS, ask clang to interpret them, and then introspect what sanitizers/sanitizer options got enabled, i'm afraid it's not really feacible
I'm not understanding. If you want Halide to enable a sanitizer, you add it to the list of target features. It's a downstream responsibility to configure Halide correctly, i.e. you're in control of your flags, so it's your responsibility to make sure that your various flags agree between all the compilers you're using.
Halide isn't and can't possibly be responsible for sniffing all the innumerable locations that -fsanitize might be slipped into the command lines of surrounding compiler invocations
There's CFLAGS, CXXFLAGS, hard-coded Makefile command lines, CMake's
add_compile_options and target_compile_options (and abuses of related functions), compiler wrappers, etc.
Yes, or dependent upon the other features that are enabled on the Target
E.g. if you combine multiple sanitizers
The Halide equivalent of a compiler command line is the Target feature set, pretty much
the unfortunate consequence of that is that each downstream will have to second-guess what clang will do, and manually tell halide do do the same