-
Notifications
You must be signed in to change notification settings - Fork 11
FAQ
The short answer is that if your code generation has no need for context information, then you can simply pass a null pointer for cdata.
The cdataargument is entirely for your own use (as the compiler writer and client of PRIF), and the contents are entirely up to you. The prif_co_reduce call accepts cdata which is an arbitrary 64-bit value that is entirely opaque to the PRIF library. The PRIF library is the one that later invokes the operation_wrapper callback while computing the reduction, and the PRIF library will pass the same cdata value back to your generated code as the fourth argument to that operation_wrapper invocation when the corresponding reduction operation callback needs to be invoked. The value is associated with a particular image's current invocation of prif_co_reduce. So for example if you needed to pass a pointer to a compiler-generated stack frame closure or other metadata from the code around the user's call to CO_REDUCE into the code which marshals the invocation of the user-provided operation callback, you could pass that pointer in the cdata argument. The second example in the prif_co_reduce section of the PRIF 0.5 specification shows how that could be used to support a user-provided operation over a (non-interoperable) derived type with length type parameters.
As another example, if the user-provided operation is known to be an interoperable procedure (or the compilers knows it can safely create a usable procedure pointer to it with a 64-bit representation), then you could pass that pointer in the cdata argument and invoke it from within the generated operation_wrapper.