(j3.2006) "Contiguous" doesn't quite do what I need

[Van Snyder]

On Fri, 2007-03-23 at 11:11 -0500, Bill Long wrote:
> 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.

The notation I propose is just as simple as the contiguous attribute,
and entirely subsumes it.  Instead of "real, contiguous :: A(:,:,:)" one
writes "real :: A(::1,::1,::1)".  Since the notation I propose entirely
subsumes the contiguous attribute, adding it later will look like a
replacement for an earlier poorly thought-through feature, preserving
what was described in the lead-up to Fortran 90 as "the beloved Fortran
tacked-on look."

> 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 
> pointer.

The "contiguous" attribute does nothing for the case of arrays known to
have extents in some (probably leading) dimensions given by
initialization expressions.  Thus, the processor cannot peel loops
involving these objects.  Pointers usually subvert the optimizer, not
help it, so any gain from using a contiguous pointer to access a
contiguous section of an array might evaporate into the morass of
pointerness.

> Cheers,
> Bill
> 
> 
> Van Snyder wrote:
> 
> >I earlier proposed a notation for an array dimension for pointers and
> >dummy arguments using [low]:[high]:[1] 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
> >redundancy.
> >
> >  
> >
>