(j3.2006) "Contiguous" doesn't quite do what I need
Fri Mar 23 12:11:16 EDT 2007
This seems like a request for mixed explicit-shape/assumed-shape
declarations. I don't see this as competing or conflicting with the
contiguous attribute. The contiguous attribute is aimed at the far more
common case where the whole array is contiguous and lets optimizers
collapse loop nests and skip copy-in/copy-out tests. The contiguous
attribute is a clean, simple, and obvious syntax for this situation.
For the common, simple case, the mixed declaration scheme seems much too
complicated and obscure. I can see a use for the mixed declarations,
but I see it as a different feature. One that could be proposed for
f2013 when the JOR is opened again.
For your example of a small contiguous section of a larger array, you
can declare a pointer with the contiguous attribute and associate it
with the section. In situations there the contiguity is useful (such as
an actual argument corresponding to an explicit-shape dummy) use the
Van Snyder wrote:
>I earlier proposed a notation for an array dimension for pointers and
>dummy arguments using [low]:[high]: to indicate that a dimension has
>an explicit extent if "high" appears, and it's contiguous w.r.t the
>earlier dimensions if "1" appears at the end.
>In some applications, I have multidimensional arrays for which I know
>apriori the first few extents from the physics of the problem, but the
>other extents vary as the calculation proceeds. The "contiguous"
>attribute would help the processor avoid digging up strides from dope
>vectors, but it won't help with loop peeling, which I hope would happen
>if, for example, the first extent is 3 or the first two extents are 2,2.
>Sometimes I know the first few dimensions are contiguous but I don't
>know about the rest. For example, if I'm integrating the 2x2 absorption
>tensor along a line of sight using a coarse grid, and then I later use a
>fine grid to get better enough accuracy. In the first case, the third
>dimension is evenly spaced but not contiguous w.r.t the first two
>dimensions (the spacing is three times bigger than it would be if the
>array were entirely contiguous), while in the second case it's entirely
>contiguous. The "contiguous" attribute can't be used in this case,
>while a dimension declaration (1:2:1,1:2:1,:) would work.
>This would let me say that a dimension is contiguous and still inquire
>the bounds using "::1", or say it's not necessarily contiguous but I
>know the extent with ":high:" or say it's contiguous and I know the
>extent with ":high:1".
>I think a lot of the words we have concerning the "contiguous" attribute
>would work with this notation. A few more words would be needed for
>allocation and pointer association to make sure the extents of declared-
>extent dimensions match up.
>I'd like to see contiguity specification done in the most useful way
>before it's cast in stone wrongly (or at least incompletely). If we
>proceed with the "contiguous" attribute and later decide we really
>should have done what I propose above, we'll end up with a warty
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
More information about the J3