[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:

Had a little think about it over the weekend and remembered another reason I opted to not do it is that the map we are removing in this case is the one that's already generated by the lowering, that we use to generate the map we keep. So we'd still basically be doing the same thing, just earlier in the pass and with more complexity, as it'd now make the logic for the initial map expansion a fair bit more complicated. So, this is the lesser of two evils I think and has the side-affect of also working for the char arrays which still needs to be tidied up to be merged in with the rest of the flow in the pass rather than be its own separate segment.

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