You generally don't want to go through the C backend if LLVM has a backend for your target
s/option/feature/
well, and tsan
We could look into enabling that pass via a feature flag, assuming one exists at the LLVM level
so msan seems obvious-ish
Sure. We could look into this if it appeases fuzzing tools generally.
let me just file a metabug first
"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