Array Descriptor Update

[Daniel Kraft]

Hi Paul,

Paul Richard Thomas wrote:
> Janne and Thomas have been contributing to a rather important page on
> the gfortran wiki: http://gcc.gnu.org/wiki/ArrayDescriptorUpdate
> 
> It starts with, "In some cases it would be nice to improve gfortran's
> array descriptors."

This is indeed interesting (I've followed the talk about array 
descriptors a bit in the past), and although I'm not really an expert on 
this topic, would like to contribute whatever I can.

> I think that it has become essential to do this as one of the first
> tasks in gcc-4.5, for the reasons given in the wiki page and to
> realise such things as allocatable scalars and, I have come to
> believe, CLASSES.  The reason it might be a good thing for classes is
> because of the need to carry a type identifier with the class pointer.
>  This could be done in the same way as character lengths, as at
> present, or as a descriptor field.  I do wonder if this is not the
> purpose of the reserved word in the Intel descriptor?

If I understand you correctly, we would have one type of descriptor that 
would be used for allocated arrays as well as allocatable scalars and 
CLASS pointers/pointees, so that would be "the" place to store the 
runtime type token?

As you mentioned character lengths, maybe we should think about length 
type parameters in general for this project?  But that's just an 
associative thought, I've no idea at the moment about what length type 
parameters really impose on the compiler.

> One thing that is noticable about the Intel and the Pathscale
> descriptors is that they carry no type or kind information, whereas
> gfortran packs this into the DTYPE word.  I started looking to see if
> gfortran uses this descriptor information anywhere and so far have
> drawn a blank; admittedly on a not very thorough search.  In addition,
> I have not seen any use of the size information either.  Does anybody
> know if it is used anywhere?

I can't answer your original question, but I believe this information is 
not really "needed" as the type is compile time known and gfortran can 
insert the appropriate handling for the type at compile time; I guess 
that's why we don't need it...  But with your proposal for polymorphic 
entities, we would want to carry a runtime type.  I guess we could 
probably drop the static type information (for CLASS(t) it would be "t") 
and replace it by the dynamic one (the runtime type).

> It crosses my mind that in order to preserve backward compatibility of
> the API, we could put extra information after the dimension fields and
> leave the latter alone.  This would have the disadvantage that the
> reform (stride, lbound, ubound) => (lbound, stride, extent) and
> handling bytes rather than words would be put off.  How important is
> backward compatibility?

What I heard from the talk about 4.3 ABI breakage, I got the idea that 
in the past each major version of gfortran broke it anyways (maybe 
except the upcoming 4.4 now?).  So for a descriptor rework in favor of 
new features like allocatable scalars or CLASS, I would see it 
reasonable to simply go along and do the best of design we can come up 
with, not introducing any kludges to try preserving the ABI.  But that's 
of course only my personal opinion, as someone who didn't really use any 
Fortran for large projects yet and does not have any compiled code lying 
around...

Thanks for bringing this up!

Daniel

-- 
Done:  Arc-Bar-Cav-Rog-Sam-Val-Wiz
To go: Hea-Kni-Mon-Pri-Ran-Tou