[RFC] Native Coarrays (finally!) [Review part 3]

[Thomas Koenig]

Hi Andre,

just one remark on one of your remarks.

+{
+  index_type count[GFC_MAX_DIMENSIONS];
+  index_type stride[GFC_MAX_DIMENSIONS];  /* stride is byte-based here.  */

###AV: When it's the stride of an array_descriptor it usually is not 
byte based,

You're correct, it is usually not byte based, but that is a design
mistake that I hope to partially rectify, at least as far as
library code is concerned, for the gcc 11 timeframe.  (This is
PR 95101, but that doesn't have a lot of explanation).

Basically, when we do something like

type foo
   integer :: i
   real :: r
end type foo

type(foo) :: a, b

and then evaluate something like

a%i = cshift(b%i,2)

we create temporary arrays for a%i and b%i.  Needless to say,
this is extremely inefficient.

The descriptor has all the necessary information in the span
field (which is byte-based), so it is my aim to use that information
directly in the library function and not to generate that temporary.

The part of that not generating a temporary is easy - it is

--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -9823,13 +9823,9 @@ arrayfunc_assign_needs_temporary (gfc_expr * 
expr1, gfc_expr * expr2)

    /* If we have reached here with an intrinsic function, we do not
       need a temporary except in the particular case that reallocation
-     on assignment is active and the lhs is allocatable and a target,
-     or a pointer which may be a subref pointer.  FIXME: The last
-     condition can go away when we use span in the intrinsics
-     directly.*/
+     on assignment is active and the lhs is allocatable and a target.  */
    if (expr2->value.function.isym)
-    return (flag_realloc_lhs && sym->attr.allocatable && sym->attr.target)
-      || (sym->attr.pointer && sym->attr.subref_array_pointer);
+    return (flag_realloc_lhs && sym->attr.allocatable && sym->attr.target);

    /* If the LHS is a dummy, we need a temporary if it is not
       INTENT(OUT).  */


but all the library functions would have to be adjusted for that.
Clearly, for the collective subroutines, we should avoid one extra
copy on entry and one on exit.

Best regards

	Thomas