[llvm] [Offload] Introduce ATTACH map-type support for pointer attachment. (PR #149036)

[Abhinav Gaba via llvm-commits]

================
@@ -2538,6 +2538,10 @@ struct AMDGPUDeviceTy : public GenericDeviceTy, AMDGenericDeviceTy {
                                           getAgent(), (uint64_t)Size);
   }
 
+  Error dataFence(__tgt_async_info *Async) override {
----------------
abhinavgaba wrote:

Thanks for chiming in, Alex.

Joseph, are you suggesting creating a new queue for the ATTACH data-transfers? If that is the case, there is no guarantee that the previous data-transfers would have finished. Which would require us doing an explicit `synchronize` between the two queues, which would not be good.

Otherwise, if we are to reuse the same queue as previous `submitData`s, then as Alex mentioned, we cannot assume that the queue is doing in-order transfers.

If we are talking aboud connecting previous `submitData`s with the ATTACH-specific `submitData`s using events, that seems like an overkill, because that would require us to create events for every `submitData` done by `targetDataBegin`, and then selectively wait for those that the ATTACH entries may overlap with, when doing a `submitData` for them. That's because when `targetDataBegin` is being run, we don't know which data-transfers may eventually collide with an ATTACH-related transfer.

The `data_fence` approach, should be the lowest-impact, most asynchronous approac, since if the underlying queue is in-order, it would be a no-op, and if it's not, and the queue supports inserion of barriers, then that would be the next option, otherwise, the device can choose to do a full synchronize if it doesn't support fences. 

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