agozillon wrote:
So, incremental increase of support if possible and get feedback as early as
possible on direction is the aim :-)
The idea for the member index, at least currently will be to move it to a
multi-dimensional index (via DenseIntElementsAttr) as an example:
```
type :: nested
real(4) :: x1
real(4) :: y2
real(4) :: z3
end type nested
type :: array
real(4) :: x
real(4) :: y
real(4) :: z
type(nested) :: nest
end type array
```
In the above case array%nest would be index: (3) and array%nest%z3 would be
index: (3, 2), if we replaced z3 with another layer through a derived type and
mapped a member of it, it would be an index of (3, 2, ...) and so on.
I am hoping that will be reasonable enough to support the case of map(tofrom:
x%y%z, x%y) and from a little IR testing it seems it should be, however, I am
still working on the initial implementation for this use-case, so I could be
wrong. The main thing I am worried about and a little unsure on currently is if
the layout of the derived type will always be segmentable like this. But there
could be other things wrong with modeling the placement of members like this
that I am missing (or a better method of doing so)! So if there is I would love
for some feedback.
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
