[Fortran-dev, patch] Use only lbound/extent/sm in the array descriptor

[Tobias Burnus]

Thomas Koenig wrote:
>> There are still 227 test-suite failures ("FAIL" lines) affecting 27
>> test-suite files. That's slightly down from the 269 lines the branch
>> currently has. (Some issues can be fixed by modifying the tree dump
>> patterns, but most seem to be "real" problems.)
>>
>> Build and regtested on x86-64-linux.
>> OK for the branch?
>
> The library parts look OK to me.

I have now commit it (Rev. 185199) - thanks for looking at the library part.

>
> There is just one point of efficiency.
> +#define GFC_DESCRIPTOR_STRIDE(desc,i) \
> +  (GFC_DESCRIPTOR_SM(desc,i) / GFC_DESCRIPTOR_SIZE(desc))
>
> In most generated files, GFC_DESCRIPTOR_SIZE is a constant known
> at compile-time (and usually a power of two), which means that the
> division can be done in a simple shift.  If we get the size from the 
> descriptor, we actually have to divide, which is expensive.

  I think one should also go through all the files and check whether one 
can replace _STRIDE by _SM. In some cases, the code actually does this: 
It calls _STRIDE and later multiplies by the byte size. I tried to avoid 
_STRIDE at some places, but I only looked at it in the context of 
setting the descriptor. Similarly, but less critical: One should check 
whether EXTENT can replace UBOUND.

Side note: c_f_pointer0 (which is called for array with shape) is 
currently broken as "dtype" is not set before the call - and thus the 
size is not known, which is required for setting the "sm". I think the 
best would be to replace it by inline code. (That's the reason behind 5 
of the 24 failing test-case files.)

> I would commit the patch now, adding
>>
>> TODO:
>> - Fixing the regressions.
>> - Cleanup of the library and the front end
>> - Switching also from ubound -> extent for nondescriptor arrays?
>> - Properly implement subpointers
> - Avoid division for GFC_DESCRIPTOR_STRIDE where possible.

Well, that's what I meant by cleanup: Trying to update the usage such 
that one avoids ubound/stride when extent/sm are required - and doing 
other optimizations like that one. Maybe one can also get rid of some of 
the macros if they are unused.

In any case, I would be happy if you could have a look.

I think the real fun will start when we have to implement the other 
parts (esp. lower_bound semantic, elem_len and in particular the type 
system of TS29113).

Tobias