skatrak wrote: After the discussion with @TIFitis yesterday, I think the overall approach currently proposed makes sense. I would just like to share a few related thoughts not for this PR stack, but rather some longer term potential improvements that might make sense to do: - I think the new `omp.declare_mapper_info` operation currently helps not having to introduce too many new features at once, and rely on the existing infrastructure as much as possible, but I believe eventually this should be replaced with an `omp.yield` of the necessary `omp.map.info` operations and potentially some changes to the verification and handling of `map` clauses. - Long-term I was thinking that we may want to represent type-dependent handling of `map` clauses in a way more similar to what we do for privatization. Initially I was thinking that we could use the `omp.declare_mapper` operation for this, but it's true that it's only intended to be used for derived types / structures. However, my thinking is that if we introduced something like an `omp.map` operation holding region(s) that define mapping for a given type of variable, we may be able to avoid the need for fix-up passes to add new mapped variables for e.g. allocatables or other complex types. Ideally, it would be able to integrate with `omp.declare_mapper` operations and unify map-related handling so that there's fewer corner cases or at least centralize that kind of logic. This is only a high-level idea at this point, not something I have actually spent time thinking through in detail, but perhaps something worth exploring at some point.
https://github.com/llvm/llvm-project/pull/117046 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
