RFA: Revamp fortran array types

[N.M. Maclaren]

On Aug 19 2009, Toon Moene wrote:
>Richard Guenther wrote:
>
>> Note however that we currently do not do interprocedural alias analysis
>> at all.  Note also that for large programs whole-program pointer analysis
>> can be quite time and memory consuming ;)
>
>Sure, I imagine that the next half-decade we will be arguing about cost 
>models (not just for code rearrangements/optimizations, but for doing 
>certain analyses in the first place) due to all the new opportunities 
>whole program analysis gives us :-)

That's a change?  The constraints were different in the 1970s, but most
of the techniques were known, and it was a hot topic then.  I wasn't in
IT in the 1950s, but have seen some relevant papers dating from then ....

Make it a century or two :-)

There is also the important point that the effectiveness of many such
analyses depends on the programming style.  Current Fortran codes rarely
use pointers in the way that they were used in (say) BCPL or are used in
C and C++.  Analysing such programs for aliasing is intractable, no matter
what language they are written in, and some algorithms are inherently like
that.  If Fortran people change their style, the problem will change.

Consider, for example, Dirichlet tesselation (or Voronoi diagrams, if you
prefer).  Many algorithms are arbitrarily parallelisable, provided that no
actions on two nodes are separated, not synchronised AND share a neighbour.
Nodes have an arbitrary number of neighbours and the structure is both
entirely data dependent and dynamically changing.  Now analyse THAT aliasing
statically!


Regards,
Nick Maclaren.