On 1/8/20 9:22 AM, Jakub Jelinek wrote:
With mixed REF_COMPONENT and REF_ARRAY, one can have var(:), or var2%comp(:)
or var3(:)%comp, or var3%comp(:)%comp2 etc.
Technically, one can also have var3(4)%comp(:)%comp2(1) – with one
nonelement/AR_FULL reference and two element references. (At least as
long 'comp2' is neither a pointer or an allocatable.)
and so the question is
what exactly we want to handle in the first if and what in the other cases.
My impression was back in October that – except for the additional
component ref – that if the last reference is an array, it can be
handled fine with the existing code AR_FULL code as a lot of the
complications was already handled when converting gfc_expr to a tree. –
But I didn't explore this back then as I stashed the project.
And something else should handle the other references, and that one needs to
walk the ref chain and handle each REF_ARRAY or REF_COMPONENT in there.
I am not sure whether one needs to handle each REF_COMPONENT and
REF_ARRAY here. Talking of OpenACC 2.6 and OpenMP 4.5, one can largely
ignore the components references before either the last one or before
the first non-element array access – and for element access after the
last component, the current code seems to map "comp(:)" when specifying
"comp(:)%comp2", which I think it is fine.
* * *
_[Otherwise, one had to map each element separately or add more mapping
support for some strided access patterns. – Depending on the element
size [sizeof(comp(1)%comp2)] vs. stride [loc(comp(2))–loc(comp(1)]
ratio, copying it as block or per element makes more sense. (Using
A(::n,::m)%a it might make even sense to combine one stride as
contiguous block and loop over the other.]_
In any case, that's something to study for Stage 1, whether first for
OpenMP 4.5 or already preparing it for OpenMP 5, is the other big question.
For the latter, I am not sure how to handle it best. (I wonder how it is
implemented for coarrays as one has there the same issue, especially
with user-defined reduction functions and polymorphic variables, it can
get complicated. – I did have an idea back then, but have not
implemented it. I wonder whether someone else has tackled it in the
meanwhile.) — I also have not checked whether OpenACC 2.7 or OpenACC 3.0
or OpenMP 5.1/TR8 will add additional complications, which should be
taken into account (at least design wise). [Nor whether new coarray
issues pop(ped) up, which should be taken care of at the same time.]
To handle polymorphic types with allocatable components (which
automatically get copied): I fear one cannot avoid adding a function to
the v(irtual)tab(le). For user-defined reduction, I was thinking of
passing a function pointer to the library, which then calls the function
and provides a function pointer to a library function – that way, one
can recursively pass calls between the library (which knows how to
transfer the data) and the vtable functions in the code (which know the
data structure).
Cheers,
Tobias
