Problem with a pipeline for converting OpenCL into SPIRV

Keryen · February 21, 2020, 1:32pm

Hello everyone,

I want to make a generic program to transform an OpenCL project into SPIRV format with the files as optimized as I can for making them faster at execution time. I am following these steps in my pipeline:

First, after finding an OpenCL project, I execute clang for convert the OpenCL files into bytecode format (.cl into .bc), using the following command:
clang -cc1 -triple spir64 -emit-llvm-bc -finclude-default-header -cl-single-precision-constant EXAMPLE.cl -o EXAMPLE.bc

After that, I execute the command llvm-spirv (from SPIRV-LLVM) to convert the mentioned bytecode into SPIRV format (.bc into .spv), executing the following command:
llvm-spirv EXAMPLE.bc -o EXAMPLE.spv

After that, I finally execute the spirv-opt (from SPIRV-Tools Project) for finding how different optimizations affect to different projects, using the command like:
spirv-opt EXAMPLE.spv -o EXAMPLE_0.spv

I am having an error in some projects when running this pipeline. When I get the code from a project and it runs the optimizator, it gives me an error. For example, when I applied all of the project called backprop from Rodinia benchmark, I got the following error:
error line 313: Block 26[%if_then65] appears in the binary before its dominator 35[%if_end55_4]
%if_end55_4 = OpLabel

After a little research, I have found the problem comes from one of the first to commands, clang or llvm-spirv. I have tried several things but I do not found exactly where and why the problem is generated. Any suggestions? I would like to continue this project for finishing my final degree project and if it works, give to the community an automatic OpenCL optimizer.

I could not put the links to the projects and benchmark, if you need them or you can help me with this problem, please email me: enrique.gonzalezr@alumnos.upm.es, I would appreciate it.

Thanks in advance!

miker256 · February 23, 2020, 12:42am

Hi @Keryen, I would take a look at this GitHub issue and see if it solves the issue.

github.com/KhronosGroup/SPIRV-LLVM-Translator

Translation from OpenCL kernel lang for inline functions

opened 03:55PM - 11 Feb 20 UTC

AnastasiaStulova

Currently we seem to have issues with translation of OpenCL kernel code that has… _inline_ functions. **(OpenCL C)** In C99 frontend doesn't generate definition of inline functions for non-optimized mode because non-optimized mode wouldn't enable inlining. If we generate IR for the following source code in C99: ``` 1 inline void foo(int* i) { 2 (*i)++; 3 } 4 5 void bar(){ 6 int i; 7 foo(&i); 8 } ``` passing -O0 flag to clang will result in IR: ``` ; Function Attrs: noinline nounwind optnone define void @bar() #0 { entry: %i = alloca i32, align 4 call void @foo(i32* %i) ret void } declare void @foo(i32*) #1 ``` **(C++ for OpenCL)** Compiling inline functions with C++ based frontends using -O0 flag results in IR where _noinline_ is added. Therefore backends might not be able to inline the functions (the inline hint information is not preserved) and the generated binary won't be as efficient even if optimizations are enabled after SPIR-V injection. ``` ; Function Attrs: noinline nounwind optnone define void @_Z3barv() #0 { entry: %i = alloca i32, align 4 call void @_Z3fooPi(i32* %i) ret void } ; Function Attrs: noinline nounwind optnone define linkonce_odr void @_Z3fooPi(i32* %i) #0 comdat { entry: %i.addr = alloca i32*, align 8 store i32* %i, i32** %i.addr, align 8 %0 = load i32*, i32** %i.addr, align 8 %1 = load i32, i32* %0, align 4 %inc = add nsw i32 %1, 1 store i32 %inc, i32* %0, align 4 ret void } ```

Keryen · February 27, 2020, 12:09pm

Hi @miker256, I have applied the flag the issue you sent said, it solves some error cases like the one I specifically post before:

Even so, I still get some errors like the following ones:

error: line 1032: Function definition (id 192) may not be decorated with Import Linkage type.
%compute_velocity = OpFunction %void None %191

error: line 271: Invalid use of function result id 108[%inCube].
OpGroupDecorate %373 %inCube %inSphere

error: line 279: 3rd operand of LoopMerge: operand PartialCount(256) requires SPIR-V version 1.4 or later
OpLoopMerge %for_cond_cleanup %for_inc PartialCount 8

The first one is from a different project, it is called cfd, also from Rodinia benchmark, it fails at Kernels.cl.

The second one is from a GItHub project called c-opencl-raymarcher, it fails at warp.cl.

The last one is another GitHub project called GRATER, it fails at approximate_kernel.cl.

stulova · March 2, 2020, 3:13pm

Are you compiling with or without optimizations?

It feels like

Could be a spirv-opt issue. You could create the issue against their repo and attached a test case to demonstrate a problem.

This might be a SPIRV-LLVM Translator issue. Again I would suggest to open an issue with a test case to make sure someone looks into this.

Keryen · March 4, 2020, 11:42am

I have validated that SPIR-V files, then I have tried to apply optimizations. That errors are given in both cases, in the validator command (spirv-val) and also in the optimizations (spirv-opt), that is because the optimizator applies also the validator before trying to optimize anything.

That makes me think that the problem cannot come from the optimizer, only from the Clang command or the SPIRV-LLVM Translator, because the error is given with no optimizations applied. I will make an issue in SPIRV-LLVM Translator project then.