low level optimization

[Jim Giles]

In article <BURLEY.91May1153042 at pogo.gnu.ai.mit.edu>, burley at pogo.gnu.ai.mit.edu (Craig Burley) writes:
|> [...]
|> Obviously, if the decision as to whether a dummy gets defined or even
|> referenced is made at run-time, then it is impossible for a compiler or
|> linker/loaded to do a complete check as to whether aliasing errors have
|> been coded into the application.

True.  The test I had in mind would signal a message whenever an instance
of aliasing occurred which _might_ be illegal.  That is, if either of the 
aliased entities is _possibly_ assigned to within the procedure (this is a 
simple thing for the compiler to determine - the variables either appear
on the left of an assignment _somewhere_ or not).  In this respect, I simply
assume that the possible will happen.  The bottom line is that any variable
with the OUT or INOUT attribute (or, one that would have that attribute if 
you made an interface for it) must not be aliased or I issue a message.

|> [...]
|> That having been said, I do think 99% or more of all aliasing errors comitted
|> in Fortran code are detectable (without falsing) at the link/load phase
|> (i.e. more than 99% are provable and obvious).

I agree.  This is also true of all C code except where pointer assignment
has been performed.  Then the issue gets muddy indeed.  The only safe
answer is that the pointers involved are now _maybe_ aliased to all
the objects in the transitive closure of assignments to which they belong.
This is also simple for the compiler to determine, but will result in 
a lot of alias warnings that aren't actually true.  Fortran pointers
will suffer the same problem.  The best solution is to extend the
languages to allow the user to explicitly declare which pointers are
allowed to be aliased and to what.  Then the compiler can actually 
enforce the constraints (at compile time).

This gets back to the issue of "empowerment".  Giving the user explicit
control is empowerment.  Automatically making the decision for him is
not.  Though, if an automatic method _mostly_ does what you want, you may
be satisfied to accept the default most of the time - just as long as
you are given the power to override the default when you want to.  With
respect to aliasing, neither Fortran nor C give you that power.  Using
the loader in the manner I've described would give the user feedback about
how to use that power most effectively - and maybe, therefore, convince
implementors and language designers to provide the necessary features.

J. Giles