(j3.2006) Question about Comment GB20 on CFI_is_contiguous
Mon Oct 3 11:15:32 EDT 2011
On 9/29/11 7:16 PM, Malcolm Cohen wrote:
> -----Original Message-----
> From: Bill Long
> Date: ?????? 23???9???29??? 13:02
> To: fortran standards email list for J3
> Subject: Re: (j3.2006) Question about Comment GB20 on CFI_is_contiguous
>> the "otherwise" specifies the result as 0. Similarly, if the descriptor
>> is for a scalar, "otherwise" wins. If the intent is to use this result
>> to employ some optimized code for the case of the result = 1, then these
>> result values give you what you need.
>> This is completely unacceptable, and *NOT* what the programmer needs at all.
> I don't understand. This is exactly what I, as a programmer, would
> want. What do you want that is different?
I see two general cases where using CFI_is_contiguous would be interesting.
1) The function expects a descriptor for an object of a particular rank.
In this case, a test for obj->rank != expected_rank would go to error
return code; otherwise the user might check for contiguous if the
expected_rank > 0. If the expected_rank is 0, then it would be
pointless to call CFI_is_contiguous.
2) The function expects a descriptor for an object of arbitrary rank.
In this case, I would test for obj->rank==0 separately. If obj->rank >
0 then CFI_is_contiguous being true would branch to code that multiplies
the extents together (effectively collapsing the loop nest) and executed
a single loop for the whole array. And generates vector code (for
systems that only vectorize for stride-1), and perhaps sends the whole
execution to a GPU. None of these optimizations would be appropriate
for a scalar, which has no extents to multiply together, and would not
benefit from vectorization. If you do not have a contiguous object,
then the less optimal code path gets executed. So, three code paths total.
>> Should the programmer be asking about a scalar descriptor (because of
>> assumed-rank), then for the scalar case he DEFINITELY DOES NOT WANT to use the
>> "unoptimised" code seeing as how the object is not discontiguous.
> The concept of "contiguous" is meaningless for a scalar. Why would you
> want to go through the optimized code? The optimization is likely
> meaningless for a scalar.
> Contrariwise, why do you want to go through the code that is set up to handle
> discontiguous chunks when there is a scalar? All that extra work to handle
Certainly would not do that. See above.
> discontiguous chunks is not only meaningless for a scalar but a pessimisation!
> The reason for asking about contiguity is not to "enable optimisation", it is to
> enable *the normal way C works* (see penultimate paragraph below).
> I'm OK with requiring that the C descriptor actually describe an object,
> As the existing text requires.
> and making it a programmer error to supply a descriptor for an
> unallocated allocatable or disassociated pointer.
> Which matches the Fortran intrinsic, and arguably follows from the existing
> text, but is not clearly stated and thus interp fodder; it would be good to have
> a clear statement like we do for several of the other functions.
> I assume this comes
> under C's undefined behavior, and the program can do what it wants.
> Umm, that's "the *PROCESSOR* can do what it pleases"... but I'm sure that's what
> you meant.
> Including returning 0, which is the useful choice anyway.
> Since ".NOT.IS_CONTIGUOUS" implies that we have an object "with gaps", and thus
> we need special processing to handle the gaps, we clearly have different ideas
> of what the "useful" return value should be. The normal C situation is that
> every object is contiguous, so it is the *discontiguous* state that is unusual,
> and also requires more work.
> Since an array with one element is contiguous, it would be more than surprising
> to discover that both "is_contiguous(scalar)" is allowed and required to return
> FALSE! I suppose having such a perverse definition might encourage programmers
> to check the rank first though... but if we are going that route, just don't
> allow "is_contiguous(scalar)".
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101
More information about the J3