[flang-commits] [flang] [llvm] [Flang][OpenMP] Defer descriptor mapping for assumed dummy argument types (PR #154349)

[via flang-commits]

================
@@ -864,6 +1047,36 @@ class MapInfoFinalizationPass
         }
       });
 
+      // Now that we've expanded all of our boxes into a descriptor and base
+      // address map where necessary, we check if the map owner is an
+      // enter/exit/target data directive, and if they are we drop the initial
+      // descriptor (top-level parent) and replace it with the
+      // base_address/data.
+      //
+      // This circumvents issues with stack allocated descriptors bound to
+      // device colliding which in Flang is rather trivial for a user to do by
+      // accident due to the rather pervasive local intermediate descriptor
+      // generation that occurs whenever you pass boxes around different scopes.
+      // In OpenMP 6+ mapping these would be a user error as the tools required
+      // to circumvent these issues are provided by the spec (ref_ptr/ptee map
+      // types), but in prior specifications these tools are not available and
+      // it becomes an implementation issue for us to solve.
+      //
+      // We do this by dropping the top-level descriptor which will be the stack
+      // descriptor when we perform enter/exit maps, as we don't want these to
+      // be bound until necessary which is when we utilise the descriptor type
+      // within a target region. At which point we map the relevant descriptor
+      // data and the runtime should correctly associate the data with the
+      // descriptor and bind together and allow clean mapping and execution.
+      for (auto *op : deferrableDesc) {
----------------
agozillon wrote:

It is likely possible, but I opted for this approach as the logic for the initial generation of the maps (this would have to be done earlier in this pass, as it can't be done in the initial lowering with the current optimisation pass direction) is already fairly complicated and I wasn't too keen on adding more complexity to it and we already have a precedence for composing things into a phased/modular modification of the maps in this pass! And at the time I didn't think it'd be as simple as a simple if check so I opted for this approach initially!

This will also have to be wrapped in an OpenMP versioning check eventually as well, as we'll likely want to switch this off when attach map semantics are implemented in the later versioning, as it shouldn't be needed as the tools will be in the users hands to avoid this issue (in theory at least).

But if we're wanting to save the cycles and don't mind adding more complexity to the initial pass, I could look into how feasible it would be to implement it earlier if you wish! Let me know :-)

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