Re: Status of array descriptor changes

[Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>]

Dear Francois-Xavier,

I think that Tobias has covered the main points. The 'span' business
is a kludge introduced (to my shame, by me) to allow some support of
the likes of:
my_int_pointer => my_derived_array%int_field

There are several PRs associated with this. It is the remaining F95
feature to which gfortran is not fully compliant. It could have been
dealt with by adding 'span' (aka 'sm' or stride measure) as a hidden
argument to procedure calls, like character lengths. However, we stood
back from this since the array descriptor reform work was started
several years ago and was 'imminent' since then... ***sigh***

fortran-dev has arrived at the point where the failures are (i)
wextra_1.f which fails on trunk too; and (ii) a couple of missed
vectorization opportunities.  Dominique has done some performance
checks with the Polyhedron suite and finds:
Quote...
(1) The compilation time is reduced by ~30%;
(2) The executable are larger, up to ~20%;
(3) linpk and test_fpu2 run ~10% slower and tfft2 ~20% slower.

(1) and (2) are somewhat surprising but (3) might be expected because
of extra accesses to the array descriptor because of the temporary
bits of code - especially for gfc_descriptor_stride_set/get, where the
'sm' and 'elem_len' fields are both accessed.  I will cross-check
Dominique's results tonight and see if my surmise is correct.

As to Tobias' point c), we could in principle continue to use ordinary
array access where we know that the element size is equal to the
dimension 1 stride measure. The only caveat is that I am not sure
whether the bounds on ARRAY_TYPE are signed or not - this would affect
the implementation of the elimination of the offset field. We could
probably do with Mikael's help since his knowledge of the scalarizer
is second to none.

Would it be a good idea to have a #gfortran meeting to discuss who
does what and when?

Cheers

Paul


On 9 June 2014 20:55, Tobias Burnus <burnus@net-b.de> wrote:
> Hi FX,
>
>
> FX wrote:
>>
>> I will have some time to contribute to gfortran in the coming months,
>> so I wondered if I could help bring the âarray descriptorâ work
>> further along. But I have not followed at all recent developments, and
>> donât know what has been done (and where), and what remains to be
>> done. Could one of you point me to a recent update on the status of
>> this project, or write a short one?
>
>
> The idea is to be 100% compatible to TS29113's array descriptor, see
> https://gcc.gnu.org/wiki/GFortranStandards#TS_29113_Further_Interoperability_of_Fortran_with_C
>
> The spec permits to have additional fields, which are listed not in the TS's
> descriptor.
>
> What remains to be done:
>
> a) A few remaining test-suite regressions.
>
> b) "offset": gfortran has an offset field, which seems to be used in some
> cases for lbound == 1 to calculate the offset. As TS29113 mandates for
> nonallocatable/nonpointer arrays that lower_bound == 0, one can presumably
> set both lower_lound and offset to zero. [The user can set the lower bound
> of the dummy argument (default: 1), but that's already taken care of in the
> callee â no need to force 1 (instead of 0) in the caller.]
> A harder step is to remove the offset field as that's also use by the
> scalarizer. The removal is not required to be standard conform, but if it is
> essentially always zero, having the extra field is a waste of space and will
> confuse other users. In any case, the mixture of nonallocatable arrays which
> use GFC_TYPE_ARRAY_UBOUND etc. in the type and those which use array
> descriptors (and have no offset, extent instead of ubound) can be confusing
> â and causes trouble when trying to remove the code.
> I think the code can also be optimized. Currently, the code checks for the
> value of the lower_bound+offset for nonallocatable/nonpointer arguments
> (i.e. assumed-shape array). But we know (already currently) that the first
> array element starts at "base_addr". Thus, there is no need to look at
> desc->lower_bound in that case.
>
> c) Finish the conversion to byte-based "sm" (stride multiplier) instead of
> element-based "stride". Currently, a lot of code uses "a[i]". But it should
> use "a+i*sm" instead to support strides which are not multiples of the
> element. Caveat: The code should be such that it can be vectorized. That
> works usually if one knows that stride == 1 or "a->base_addr +
> i*TREE_SIZE(a->base_addr)". But it fails if one has "a + i*a->sm" as the
> compiler often does not see that "elem_len" == TREE_SIZE == sm. Thus, one
> has to be careful with the conversion and how one sets "sm" and "elem_len.
> That affects the code through out the compiler, but what should come first
> is the conversion of gfc_conv_expr_descriptor.
>
> I think those are the most important early items. Next come:
>
> d) Conversion to use "elem_len" for arrays of strings. That's required for
> TS29113 with BIND(C) â and could simplify some intrinsics which currently
> take internally an array descriptor and a string-length argument. For
> TS29113, we also need to use a descriptor with scalar strings for BIND(C).
>
> e) I think we should add a field/component for a CLASS pointer to the
> descriptor. At least for CLASS arrays and in particular for CLASS(*) [also
> for scalars] it would make the live easier as one then has space to store
> the string length for CLASS(*), pointer :: p => string. The current work
> around of storing the string length in the virtual table does not work well
> (and fails for allocatable string lengths.)
>
> Tobias



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy