Halide generator to produce c++ file...

[Honya2000]

Hallo,

I'm trying to integrate Halide generator to my cmake project and have issues with debug configurations...
Following examples i setup generator this way:

find_package(Halide REQUIRED)

add_halide_generator(resize.generator SOURCES halide/rgb_resize_generator.cc)

add_halide_library(halide_ResizeRgb FROM resize.generator GENERATOR resize_generator)

And final step - I link halide_ResizeRgb to my project.

But there is problem with debug build configuration.
It fails because of runtime libs mismatch between generated lib and Halide compiler GenGen:

halide_ResizeRgb.runtime.vcxproj -> halide_ResizeRgb.runtime.lib
16>Halide_GenGen.lib(GenGen.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in resize_generator.obj
16>Halide_GenGen.lib(GenGen.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in resize_generator.obj

Actually i expected Halide generated c++ source file instead of obj / libs. So i can then include this c++ file to the project and can easily step into functions with the debugger in usual way.

But unfortunately i didn't find the way how to produce c++ sources instead of object files.
With c++ sources with all required optimizations - loop unrollings / simd intrinsics, etc - it would be portable for any platform, like wasm, linux, windows, etc. And also this would work under visual studio debugger,

Any help please ?

[alexreinking]

Actually i expected Halide generated c++ source file instead of obj / libs. So i can then include this c++ file to the project and can easily step into functions with the debugger in usual way. But unfortunately i didn't find the way how to produce c++ sources instead of object files.

Halide does have a C++ backend; however, you probably don't want to use it. Our standard CPU backends go through LLVM directly, which typically leads to better performance than we could get by generating C++ code. Basically the reason is that we have specialized information about Halide programs (e.g., bounds, pointer aliasing, vector instructions, etc.) that is simpler to communicate in the IR directly. The C++ backend mostly exists to support scenarios where LLVM lacks support.

That said, It can be accessed via the C_BACKEND argument to add_halide_library. See the docs here: https://halide-lang.org/docs/md_doc_2_halide_c_make_package.html#add_halide_library

With c++ sources with all required optimizations - loop unrollings / simd intrinsics, etc - it would be portable for any platform, like wasm, linux, windows, etc.

This is untrue. Different platforms have different SIMD models. What works well on x86 does not necessarily work well on ARM or vice-versa.

And also this would work under visual studio debugger

We are always open to hearing proposals to improve the debugging experience. As far as I am aware, the VS debugger will allow you to step through the compiled assembly.

[Honya2000]

But i'm still not aware how to solve debug build.

if I change cmake this way:

add_halide_generator(resize.generator SOURCES halide/rgb_resize_generator.cc)

add_halide_library(halide_ResizeRgb
FROM resize.generator
GENERATOR resize_generator
NAMESPACE tmrw
NO_THREADS
FEATURES c_plus_plus_name_mangling
C_BACKEND
C_SOURCE
)

It is really produces cpp file... in release build.
But still fails in debug configuration on the project resize.generator with error:

Halide_GenGen.lib(GenGen.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in resize_generator.obj
16>Halide_GenGen.lib(GenGen.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in rgb_resize_generator.obj
16

Regarding portability, i'm aware about SIMD difference in different platforms / architectures. But currently i need just SSE4.1 which works in both x86 and wasm.

So i need just cpp output for now...

[alexreinking]

But there is problem with debug build configuration.
It fails because of runtime libs mismatch between generated lib and Halide compiler GenGen:

Can I ask how you acquired or built Halide? If via pip, I should specify that it is release-mode only (providing debug binaries is a TODO).

To get you unstuck for now, you can set CMAKE_MSVC_RUNTIME_LIBRARY to MultiThreadedDLL (say, via the -D flag at the command line or in a preset).

If you don't want to set that globally, you could add this after the call to add_halide_generator:

set_property(TARGET resize.generator PROPERTY MSVC_RUNTIME_LIBRARY MultiThreadedDLL)

[Honya2000]

This is part of the cpp code produced in debug config:

int64_t const _298 = (int64_t)(_17);
int64_t const _299 = (int64_t)(_14);
int64_t const _300 = _298 * _299;
int64_t const _301 = (int64_t)(_20);
int64_t const _302 = _300 * _301;
int64_t const _303 = (int64_t)(_30);
int64_t const _304 = (int64_t)(_27);
int64_t const _305 = _303 * _304;
int64_t const _306 = (int64_t)(_33);
int64_t const _307 = _305 * _306;
int64_t const _308 = _299 * _301;
int64_t const _309 = (int64_t)(0ll);
int64_t const _310 = _309 - _308;
bool const _311 = _308 > _309;
int64_t const _312 = (int64_t)(_311 ? _308 : _310);
uint64_t const _313 = (uint64_t)(_312);
uint64_t const _314 = _313;
uint64_t const _315 = (uint64_t)(2147483647ull);
bool const _316 = _314 <= _315;

I guess generator produces such unreadable code from llvm backend...

[alexreinking]

Yeah, the C++ backend is really not meant to be human readable. I strongly suggest proceeding with the standard LLVM backends.

[Honya2000]

Ok, found some free time to continue experimenting with Halide. I'm fully lost again. What do you mean "proceeding with the standard LLVM backend". How this can help me debugging the code? With C++ backend i can at least enter the code (even if it not human readable) with debugger. But with LLVM - there is no way to debug at all.

P.S. I tried to switch to LLVM backend and as expected debugger just jumps my function over, since it doesn't have any debug information...

[Honya2000]

There is one more question.
How to connect prebuilt halide release to my cmake project?
Currently i'm using
find_package(Halide REQUIRED)
and cmake finds it somewhere in Python side packages. But... this way it doesn't work for WASM build. It just reports that couldn't find Halide.
I checked Halide cmake docs, and it states, that only requirement is to use: find_package(Halide REQUIRED)

But how this suppose to work with prebuild release.
Also i guess WASM build still cannot work with prebuild binaries? Since it requires Halide runtime library in the end which is not part of those release packages.
So how to cross compile AOT generator for wasm without full Halide building with all this huge LLVM stuff ?

[alexreinking]

When using Emscripten, you need to cross-compile... there's some documentation on that here:

https://halide-lang.org/docs/md_doc_2_halide_c_make_package.html#cross-compiling

[abadams]

Traditional stepping debuggers aren't that useful to debug Halide pipelines. I'm not sure what you're trying to do exactly, but here are some general debugging Halide tips:

If you're debugging bad output, I usually compute_root everything and then use Func::debug_to_file or print_when wrapped around individual Exprs to inspect individual values to see why I'm not getting the output I expect. There are also the trace_* methods on Func, but those tend to produce a lot of output.

If you're debugging a segfault it's almost always due to a malformed input or output halide_buffer_t. Try adding -debug to the target to see the fields of the halide_buffer_ts that are being passed. Maybe there's a bad stride or host pointer. You can combine this with a tracing method or target flag to see what the pipeline was doing when it crashed. You can also get segfaults if you turn on no_asserts and then pass a too-small input. Definitely don't use no_asserts while debugging anything and only turn it on if there's a measurable performance benefit (it very rarely helps performance - it's mostly for saving code size).

If you want to understand the structure of the computation that your schedule implies and how that corresponds to the assembly generated, compile to conceptual_stmt_html and open it in a browser.

If you're debugging a performance issue, use the -profile target flag to see where all the time is going, and then go inspect that stage in the conceptual_stmt_html output to see what might be making it slow. If the inner loop looks great, maybe it's running more than you expect. Func::trace_realizations can help diagnose this.