Comment 7 for bug 987905

Unfortunately no. Personally I see passing structs to kernels as a portability trap due to the various ways structs can be laid out in memory, so this hasn't caused us trouble in our work projects as we have avoided such code. Also, one can always work around it by using a pointer to the struct. Thus, it hasn't been on top of my personal priority list, and seems the situation has been the same for other developers of pocl.

I cannot promise any delivery time for this feature from my side as I have my hands full with higher priority features, but if you (or anyone else) wishes to contribute to pocl development, and get this admittedly irritating bit done with, I can give some pointers:

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20121224/070445.html

This patch can be mimicked on how to add a possibility to set OpenCL kernels at source level to force the SPIR_KERNEL calling convention for kernels. This calling convention would be nice as it would then be the same for all targets, and the arguments are always at a matching position to the clSetKernelArg.

Now it seems it's not possible to force the particular CC without using the SPIR target for building, which is overkill and might ruin optimizations (like Kalle pointed out at the list) unless we figure out a handy way to convert the SPIR target back to the real target before optimizations.

The other way is to look at the argument metadata and create a launcher that casts from the clSetKernelArg args to the real types before calling the kernel which is in the target's CC. IMO the single kernel calling convention way is much cleaner and should be relatively easy as there's a patch we can mimic to add the needed parts to Clang. Then we just need to #define the 'kernel' keyword to '__attribute((spir_kernel))___ kernel' or similar and we get a kernel we always know how to call regardless of the target ABI/CC.

Furthermore, I did only a quick look at the Clang sources so there might be an even easier way to override the CC for the kernels now that we access the Clang/LLVM API directly instead of via the opt/clang binaries.