Tutorial lesson_12 fails to run, reporting compile failure.

[1dbup]

Hi

I'm working my way through the halide tutorials on Odroid XU4, Linux 18.04.4, armv7l.
Lesson_12 seems to compile ok but when running, aborts with a build failure. Tried running with
HL_DEBUG_CODEGEN=3 and the last part of debug is as follows:

Testing GPU correctness:
Realizing Pipeline for target(arch_unknown-0-os_unknown)
jit-compiling for: target(arm-32-linux-jit-opencl-user_context)
Reusing old jit module compiled for :
target(arm-32-linux-jit-opencl-user_context)
custom_print: 0xb6f20fbc
custom_malloc: 0xb6f22000
custom_free: 0xb6f2205c
custom_do_task: 0xb6f1ffac
custom_do_par_for: 0xb252d130
custom_error: 0xb2deec11
custom_trace: 0xb2526000
JIT input Image argument b0 @ 0x55d2c0
__user_context @ 0xbef8ea44
JIT output buffer @ 0x7fac90, 0
Calling jitted function
Error: CL: clBuildProgram failed: CL_BUILD_PROGRAM_FAILURE
Build Log:

:127:8: error: casting to void is not allowed (void)_38; ^

error: Compiler frontend failed (error code 59)

Is armv7l supported??

Regards

[dsharletg]

The thing that is failing is:

 int _38 = 0;
 (void)_38;

Which really is valid OpenCL C. The target you are running on appears to not be a compliant implementation.

It comes from here: https://github.com/halide/Halide/blob/master/src/CodeGen_C.cpp#L2806

That line can be commented off and the tutorial (still) works, but that may not be a suitable workaround in general. I suspect that is there to avoid issues with unused declarations in other contexts on other OpenCL implementations.

[1dbup]

Hi Dillon
Thanks for your response, as I only downloaded the pre-compiled Halide, I didn't have any source files to look at.
I've been using the XU4 for around three years. It has an octa-core processor, 4 off A15 and 4 off A7 with a twin T628 GPU which is OpenCV 1.2 compliant. We had some success using OpenCL via the Mali dev kit until ARM withdrew it. Since then I have been using it with OpenCV3 for an image processing concept and Arm Compute Library to provide some potential acceleration and power reduction figures for this subject, by migrating part of the processing to GPU. I had wanted to use both in unison for an image processing topic, however ACL uses C++11 and OpenCV3 only used C++99 so couldn't be mixed. Since OpenCV4 has become available C++11 is now on the cards and I am moving forward to see if I can merge the two.
Halide looked an attractive solution/addition to this work but inability to drive the GPU in this case may mean have to go back and look at the original merging task.

[dsharletg]

Let me take a look and see if we can change the code generation here to avoid this.

I suggest also reporting the issue to the OpenCL vendor, because I really think this should be valid OpenCL C.

[dsharletg]

I'm pretty stumped on finding a portable way to deal with this. CodeGen_C assumes C++, so for that, I think we should do:

template <typename T>
void unused(const T&) {}

But for OpenCL C, I can't find something that I think will work on every OpenCL C compiler (except (void)x, which really should work).

Another option is that perhaps these only ever result from gpu_thread_barrier calls, which don't actually return an int. If we had a void type for Expr/Call, we could avoid ever generating an unused declaration in the first place.

Another option is to simply allow the unused variable warnings to exist. This probably isn't that bad? In that case, we could use the unused function above for C++ codegen, and define unused(x) for OpenCL C.

The only other option I can see is to provide a few different options as target flags, and let people choose them. @vksnk @steven-johnson @abadams any ideas?

[abadams]

It is always legal to cast scalar types to int?

void unused(int) {};
...
unused((int)x);

[dsharletg]

As far as I can tell, unnamed function parameters are not legal in C. For example: https://stackoverflow.com/questions/3487135/unnamed-parameters-in-c

I just had a horrible idea to use varargs:

void unused(...) {}

But I'm not sure that this is safe without using the va_start macro stuff, or if varargs are even legal in OpenCL C at all.

[abadams]

What about unused function parameters, are those going to cause a warning?

[dsharletg]

I don't think there is a big difference between unused vars and unused function parameters. It seems likely that at least some compilers will warn on some of these.

I think we should use the template unused for plain CodeGen_C, and just leave variables unused for OpenCL C. My guess is we never cared about warnings in that case, only CodeGen_C (which produces headers/code compiled by host compilers not running at runtime).