PyOP2 kernels are not portable

[kynan]

One of the claims of PyOP2 is portability of kernel source, however that's not currently true: When providing a kernel as a C string one needs to special case for host and device backends at the moment: host backends pull the iteration space inside the kernel, device backends don't.

This would be fixable if the kernel signature was generated by PyOP2 based on the arguments. I can see two potential ways of getting there:

1. Make the argument list (and the access descriptors) part of the kernel object. This would also allow cross-checking with the par_loop arguments when entering a par_loop.
2. Lazily generate the kernel signature when entering a par_loop based on its arguments.

[FabioLuporini]

I'm probably beind dump here, and surely there's something I'm missing, but what is the advantage of portability of kernel source? What is "portable" now is the kernel ast produced by the higher layer, which is backend-independent.

For what concerns the potential solution, I agree with you. That'd fix the "issue".

[dham]

Portable AST is not a complete solution unless we want to drop the ability to hand-write kernels.

Putting the arguments in the kernel requires some careful thought. We clearly can't put all of the arguments in the kernel or we lose all kernel reusability. What one would actually have to put in the kernel is some of the argument metadata.

[FabioLuporini]

OK, I see.

In the perspective of having a parser for hand-written kernels, which I think sounds reasonable, couldn't it just work?

[kynan]

@dham You're right I should have been more clear what I mean by "making the argument list part of the kernel": We'd still have the par_loop call with the list of actual arguments. The kernel would have some metadata on those arguments: I think name, type, shape and access descriptor would be sufficient to generate the signature. We could then drop the access descriptors from the par_loop args, which is something you have argued for in the past iirc.

[wence-]

No longer relevant after #507.