agozillon wrote: > I'm not sure if member placement alone is sufficient. As I commented in the > other PR, for `x%y%z` we need to map the `z` component of the flattened > structure of `x`, which we don't have a representation of.
It will be extended in a subsequent PR to have N-D indexing, rather than just the 1-D that's currently here, it's only intended to handle the example cases in https://github.com/llvm/llvm-project/pull/82850 for the moment. Which effectively amounts to only being able to map the first layer of a derived type, so no nested derived type member maps. Adding support for derived type member mapping is going to be an iterative process, with support added incrementally, as otherwise the PR would be a little extreme for any reviewer (as well as the fact I am building on the support piece by piece, as has been the case with all of the map work). Current plan is to add gradual map support for the following cases related to derived types: - Nested/recursive derived type member mapping (my bad terminology for the case you brought up) - descriptor type member mapping (allocatable/pointers/target) (is a case of the above, but will likely come with some caveats due to the nature of these types) - Recursive derived type mapping of all pointer/allocatable members (whenever a derived type is mapped, all these components are supposed to be mapped as well magically) - Mixed full struct map with member map (not really something required in Fortran I think, but it's something C/C++ allows in the case where you map a structure then explicitly map data pointed to by a pointer member) https://github.com/llvm/llvm-project/pull/82851 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
