[flang-commits] [flang] Skip POINTER components in implicit mapper generation (PR #177848)

[Jakob Fuchs via flang-commits]

jfuchs-kmt wrote:

> Thank you, that runtime trace looks fine to me, it's only mapping the data for arr from what I can see at least. So it's a bit odd it magically has the data on the device to do what it's doing here. However, if NVIDIA GPUs are anything like AMDs then there is possibly something like USM or XNACK (address translation not acknowledged) at play, the former obviously having unified memory so technically the data is always available, the latter being something that will effectively move the data if it is not available at time of checking it for usage, so effectively moving the data to device for you. For AMD either of these would pop up in the OpenMP runtime trace as active, but I don't know if it'd do that for NVIDIA or if there's something else at a lower layer doing something like this. Unfortunately, I don't know enough about NVIDIA GPUs to have an more educated guess though, so perhaps someone else can provide an answer :-)
> 
> But as far as I can tell the runtime and compiler seem to be doing the correct thing with regards to not mapping the pointer data. And if it was a mapper being triggered, like this PR was trying to prevent, you'd see it in the MLIR and the runtime trace (there would likely be more maps in the trace that look different to the regular ones, and MLIR has a specific mapper field for maps and operation with a region for the mapper itself).

Thank you for your looking into this. I just tried a simple C++ snippet that accesses some memory that is allocated on the host without any map clauses. In C, the runtime should have no idea how to map this since it is just a pointer. This crashes (as expected) on my Radeon R9700. On my RTX 5070 Ti, the snippet executes without any crash and I can access the modified memory back on the host. I guess that the NVIDIA card has some kind of built-in unified memory that I did not know about. Now this is more clear, I'll close my original issue!

https://github.com/llvm/llvm-project/pull/177848