Array Descriptor Update
Paul Thomas
paul.richard.thomas@gmail.com
Fri Sep 26 12:29:00 GMT 2008
Daniel,
> 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?
That's what I was suggesting. This is such a descriptor, based on Intel's.
typedef struct
{
size_t extent; ! No of elements
size_t stride; ! distance between elements in bytes
size_t lbound; ! lower bound
}
gfc_dimension;
typedef struct
{
type *data; ! base address
size_t size; ! size of an array element in bytes
void *offset; ! offset to the start of the array
size_t flags; ! allocated/can be deallocated/contiguous
size_t rank; ! 0-7
size_t type_key; ! key based on type name + module name
gfc_dimension *dimension; ! [rank]
}
gfc_array_descriptor;
I have proposed size_t for consistency with Intel.... as I understand it:-)
>
> 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.
The above descriptor could, in principle, represent character arrays and
scalars.
> 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).
At present, the DTYPE field is only long enough to allow for the
intrinsic types. Also, I suspect, it is assiduously written and copied
but then not used .... that was my question.
> 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...
I suppose that we could, horror of horrors, have a
-fuse-oldtime-descriptors???
The task of conversion is going to be big and this will be an
industrial-scale regression causer. That said, I think that it would be
worth it, as you say. I guess, in addition, that we should change to
TREE-SSA array types whilst we are about it?
Cheers
Paul
More information about the Fortran
mailing list