triSYCL / sycl

SYCL for Vitis: Experimental fusion of triSYCL with Intel SYCL oneAPI DPC++ up-streaming effort into Clang/LLVM
Other
107 stars 19 forks source link

[SYCL] POCL SPIR Builtin Translation #10

Open agozillon opened 5 years ago

agozillon commented 5 years ago

As an extension to https://github.com/triSYCL/sycl/issues/9 there are currently some incorrectly mangled SPIR builtins in POCL (https://github.com/pocl/pocl/issues/698) that will need to be handled for clean execution of SYCL spir-df output by a POCL runtime.

The incorrect mangling appears to be caused by some type aliasing via using declarations in POCL's _builtin_renames.h file and currently affects a significant amount of math functions, some atomics and printf.

I can currently see this being handled in one of two ways:

franz commented 5 years ago

Hello,

This was partially resolved in git master. There is now a script, which generates a "wrapper" with correctly mangled SPIR names, calling the pocl's kernel library functions. Partially resolved because it does not contain every possible SPIR opencl name (vectorized ones are missing, plus a few others), and it's only for the CPU device.

some reason behind the renaming of these builtins that could be a far reaching problem

The original reason (at least IIRC) was that many kernel library functions were calling libc's math functions, so to avoid name clashes, pocl renamed kernel functions with macros. This is no longer an issue as pocl doesn't use libm anymore. But unfortunately removing the rename macros doesn't solve the problem. There are two reasons:

  1. Argument address spaces. SPIR has fixed address space numbers, but pocl's kernel library uses target address spaces, which are different for every device. E.g. in the library for CPU device, all OpenCL AS map to a single target AS: zero; while library for CUDA uses SPIR numbers (IIRC). This has to be handled somewhere by address casts.

  2. The calling convention. SPIR has its own LLVM calling convention (spir_func), while pocl's kernel library use their target's. Certain passes in LLVM have a feature, where if a function is called with the wrong convention, it's replaced by "llvm_unreachable".

So for these reasons, i've created a python script which generates said wrapper. Please give it a try (via pocl git master) when you have time.

agozillon commented 5 years ago

Thank you very much for looking into this and updating us, I'll take a look into this to make sure when I get a chance! And thanks for the detailed breakdown of the problem.