🚀 go-pugleaf

In article <S4U2APBggpc2@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
> [...]
>The second statement is irrelevant, because arrays can also be
>arbitrarily aliased. Fortran sidesteps this problem by declaring that this
>aliasing is illegal, but really doesn't provide a mechanism for ensuring
>that no illegal aliasing is going on. 

Neither the Fortran standard NOR the C standard provide mechanisms for
implementing or insuring ANYTHING.  The mechanisms are the responsibility
of the implementor.

As it happens, the implementaion of a test for illegal aliasing is
fairly simple.  (It consists of having the optimizer tag the data
flow graph every time it took advantage of the fact that aliasing
was illegal.  The entry sequence for the procedure would then check
all the flagged dependencies and issue an error if any of them _really_
were dependencies.  This entry sequence test would be as fast as the
3-tuple test you proposed as a method in C for determining which version
of a loop to take.)  The fact that few (if any) implementations have
an option to turn on run-time alias detection is not because it is
hard to do (it isn't) but because there has been no demand for such
a feature.  The error of aliasing things illegally rarely occurs.

The ability to detect aliasing at compile-time is hampered by the
need to do interprocedural analysis.  This the compiler can't do
in the presence of separate compilation.  If, on the other hand,
the loader did code generation, it could detect the aliasing and
generate code accordingly.  If this technology were widely available
and acceptably cheap, I suspect that the Fortran committee would
remove the constraint against aliasing in procedure calls.

C generates slow code by default in order to cater to a rarely needed
ability to alias arguments through the procedure call.  Fortran 'sidesteps'
the problem by always generating better code.  The test for aliasing
(which I agree should be available) is possible, but few compilers
have it because few users run into the problem.

J. Giles