[cfe-dev] Comparison of 2 schemes to implement OpenMP 5.0 declare mapper codegen

Finkel, Hal J. via cfe-dev cfe-dev at lists.llvm.org
Fri Jun 28 20:46:02 PDT 2019


Hi, Alexey, Lingda,

I haven't been following this closely, so a few questions/comments:

 1. Recursive mappers are not supported in OpenMP 5, but do we expect that to change in the future?

 2. Our experience so far suggests that the most important optimization in this space is to limit the number of distinct host-to-device transfers (or data copies) on systems where data needs to be copied. In these schemes, where does that coalescing occur?

 3. So long as the mappers aren't recursive, I agree with Alexey that the total number of to-be-mapped components should be efficient to calculate. The counting function should simplify to a trivial expression in nearly all cases. The only case where it might not is where the type contains an array section with dynamic bounds, and the element type also has a mapper with an array section with dynamic bounds. In this case (similar to the unsupported recursive cases, which as an aside, we should probably support it as an extension) we could need to walk the data structure twice to precalculate the number of total components to map. However, this case is certainly detectable by static analysis of the declared mappers, and so I think that we can get the best of both worlds: we could use Alexey's proposed scheme except in cases where we truly need to walk the data-structure twice, in which case we could use Lingda's combined walk/push_back scheme. Is there any reason why that wouldn't work?

Thanks again,

Hal

On 6/28/19 9:00 AM, Alexey Bataev wrote:

Hi Lingda, thanks for your comments.
We can allocate the buffer either by allocating it on the stack or calling OpenMP allocate function.
With this solution, we allocate memory only once (no need to resize buffer after push_backs) and we do not need to call the runtime function to put map data to the buffer, compiler generated code can do it.
But anyway, I agree, it would be good to hear some other opinions.
--------------
Best regards,
Alexey Bataev


...

--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190629/fe55f801/attachment.html>


More information about the cfe-dev mailing list