gfortran IRC meeting?

[Janne Blomqvist]

On Fri, Mar 25, 2011 at 16:17, Paul Richard Thomas
<paul.richard.thomas@gmail.com> wrote:
> On Fri, Mar 25, 2011 at 1:57 PM, Tobias Burnus <burnus@net-b.de> wrote:
>> Paul Richard Thomas wrote:
>>>
>>> I thought that you might take that view of array descriptors, Tobias
>>> :-)  We will have to discuss how to do it; the stumbling block for me
>>> is the dimension triplet.  The rest is even easy but tedious.
>>
>> What's actually the issue about the dimension triplet? Which information to
>> include? The performance?
>
>>
>> CFI_index_t lower_bound; equal to the value of the lower bound of an array
>> for a specified dimension.
>> CFI_index_t extent; equal to the number of elements of an array along a
>> specified dimension.
>> CFI_index_t sm; equal to the memory stride for a dimension. The value is the
>> distance in bytes between the beginnings of successive elements of the array
>> along a specified dimension.
>
> This is what is already implemented in fortran-dev.  The stumbling
> block is to make it work!  It is a while since I looked at it but
> there were quite a few regressions.  I determined that quite a lot of
> work is required get rid of all the regressions; especially in the
> library.

Hmm, I was thinking that the library should be the easy part, as there
was a patch committed quite a while ago that hides direct access to
the dimension triplets behind macros. Thus changing from (lbound,
ubound, stride_in_elements) to (lbound, extent, stride_in_bytes)
should be doable just by changing the macros? Or at least that was the
grand idea, I suppose; as usual, it seems reality was a bit uglier?

>  In the end, I am not entirely convinced that there will be
> any benefit in terms of performance, so the task seems like a lot of
> pain for little outcome.  For that reason, I want to share the load
> and this is what I want to discuss.
>
> BTW implementing the TR is easy - remember that one of the fields in
> the TR descriptor is a pointer to the internal representation, which
> could be as at present.

In one of the earlier TR drafts, yes, but that field has been removed.
OTOH currently the TR doesn't specify the entire descriptor structure,
only which fields must be present, thus allowing vendors to add other
fields. So yes, it would be possible that one of those extra
vendor-specific fields could be a pointer to the actual Fortran
descriptor, but that approach would have the maintenance and
performance disadvantage of requiring to allocate two descriptors and
keeping them in sync. In light of this, IMHO Tobias' suggestion to use
the TR descriptor as the native one would be preferable.


-- 
Janne Blomqvist