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
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
Halide goes through LLVM for codegen, never passes through clang (unless you go through the C backend and choose to)
as far as i understand, unless explicitly enabled via halide target features, halide will not apply ASAN/MSAN, which makes sense
but the caveat is, said codebase will need some glue somewhere to toggle said halide features when the original C code would have been compiled with said sanitizers
this could look like either a cmake option in downstream code, say "WITH_ASAN", which would toggle halide feature alongside with adding -fsanitize=address to the compilation options like it did already
if (WITH_ASAN)
list(APPEND Halide_TARGET_FEATURES asan)
endif ()
Or in a toolchain file:
# ...
set(CMAKE_C_FLAGS_INIT "-fsanitize=memory ...")
set(HALIDE_TARGET_FEATURES "msan")
# ...
Yeah, I don't see that as a problem. I don't see any reason Halide should privilege CFLAGS above any other method of specification. It's not standard across all supported platforms and it's not complete on any platform. It's also likely to lead to surprising behavior in other places. No compiler that I'm aware of sniffs CFLAGS. Build systems, yes; compilers, no.
I could see maybe introducing an analogous environment variable like
HLFEATURES
alexreinking: like in previous occurrences, by CFLAGS i don't literally mean the env variable, i mean the argument list that would have been passed to the clang/compiler
Okay, but what if you're using GCC's coverage implementation?
We cannot be in the business of parsing third party compiler command lines