[RFC][WIP Patch] OpenMP map with iterator + Fortran OpenMP deep mapping / custom allocator (+ Fortran co_reduce)

[Tobias Burnus]

On 06.12.21 16:16, Jakub Jelinek wrote:
> I think there is no reason why the 3 arrays passed to GOMP_target_ext
> (etc., for target data {, enter, exit} too and because this
> affects to and from clauses as well, target update as well)
> need to be constant size.
> We do a lot of sorting of the map clauses especially during gimplification,
> one question is whether it is ok to sort the whole map clause with iterator
> as one clause, or if we'd need to do the sorting at runtime.

Regarding sorting at runtime: It looks as if Julian's patches at
  [PATCH 00/16] OpenMP: lvalues in "map" clauses and struct handling rework
can do without run-time sorting.

Regarding the sorting and iterators: I think we already have this problem
intrinsically – for depend/affinity, we create for <clause>(iterator(...) : a, b)
a single loop - also to have a consistency with regards to the array bounds.

But if we want to put 'd' between 'a' and 'b' - we either need to split
the loop - or 'd' cannot be put between 'a' and 'b'. That's a fundamental
issue. I am not sure whether that's a real issue as all have the same map
type, but still.

> but I'd
> prefer not to outline complex expressions from map's clause as separate
> function each, it can use many variables etc. from the parent function
> and calling those as callbacks would be too ugly.

I concur that it would be useful to avoid using callbacks; it it seems
as if it can be avoided for iterators. I am not sure how well, but okay.

But I have no idea how to avoid callbacks for allocatable components in
Fortran. For

type t
   type(t), allocatable :: a
end t
type(t) :: var

(recursive type) - it is at least semi-known at compile time:
   e = var;
   while (e)
    { map(e); e = e->a; }
I am not sure how to pass this on to the middle end - but
code for it can be generated.

But as soon as polymorphism comes into play, I do not see how
callbacks can be avoided. Like for:

   class(t) :: var2

Here, it is known at compile time that var2%a exists (recursively).
But the dynamic type might additionally have var2%b(:) which in turn
might have var2%(:)%c.


I see two places for calling the callback: Either by passing the
Fortran callback function on to libgomp or by generating the
function call handling inside omp-low.c - to populate a nonconstant
array.

Which solution do you prefer?

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955