Re: Another array reference dependency improvement

[Brooks Moses <bmoses at stanford dot edu>]

Roger Sayle wrote:
> In gfc_check_element_vs_element we could return GFC_DEP_EQUAL for
> two unordered scalar subscripts (elements).  Originally, when
> examining subscripts if we discovered that X and Y were unordered
> in a(X,...) vs. a(Y,...) we'd return GFC_DEP_NODEP (a bug) which was
> treated by the caller like X<Y or X>Y, and incorrectly returned
> "no dependency" without examining the "...".  This was fixed
> yesterday by taking the pessimistic assumption that unordered X
> and Y, should return GFC_DEP_OVERLAP.  This causes the caller to
> inspect the remaining dimensions such that if it finds a later
> NODEP, there's no dependency as in a(X,0,:) = a(Y,1,:) where
> the 0 != 1 guarantees independence.  The tweak below is to
> optimistically/safely return GFC_DEP_EQUAL, which again forces
> the examination of "...", but allows us to notice independence
> at the end.  i.e. elements that return GFC_DEP_EQUAL are effectively
> ignored in the dependency analysis.
>
> Fortunately, there's a whole paper on this, if the above explanation
> wasn't too confusing.  dependency.c actually does slightly better
> (or will shortly be slightly better) than the analysis described in
> that paper, which was used in SUN's and Cray's F90 compilers.

It seems to me that a simple way of explaining this would be that, if 
the indices are scalar and their relationship is unknown, there are two 
possibilities -- GFC_DEP_NODEP and GFC_DEP_EQUAL.  GFC_DEP_OVERLAP is 
not possible, and GFC_DEP_EQUAL is the most pessimistic of the two that 
are possible, so it is what should be returned.

(It also seems to me that the "This used to be GFC_DEP_OVERLAP" 
statement in the comment is likely to be more confusing than useful in 
the long run.)

- Brooks