low level optimization

[Craig Burley]

In article <22983 at lanl.gov> jlg at cochiti.lanl.gov (Jim Giles) writes:

   In article <5475 at goanna.cs.rmit.oz.au>, ok at goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
   |> [...]                     Can Fortran Extended pointers be used for this
   |> If Jim Giles accompanied his criticism of C for allowing aliasing
   |> with a swipe at Fortran compiler vendors whose products do not by
   |> default warn users when they commit the "error" of aliasing, then
   |> I'd be impressed by his fairness.

   Quite so.  I have always criticized Fortran implementations for this.
   Especially since it does not require a run-time test.  If the compiler
   were to put the proper information into the object code, the loader
   could propagate the identities of procedure arguments through the 
   call chain and detect all such illegal aliasing at load-time.  It is,
   in fact, almost the same algorithm that I've been recommending for use
   to optimize C code at load-time.

Uh, maybe "all obvious cases of illegal aliasing", but not all cases.

Remember that whether a given definition occurs, even of a dummy argument, is
entirely a run-time decision.  I.e. the statement "Dummy argument X is
defined by MATADD" is not really the opposite of the statement "Dummy argument
X is not defined by MATADD".  Instead, the statements must read as follows
to be opposites: "Dummy argument X is known to be defined during any
invocation of MATADD"; "Dummy argument is not known to be defined...".

(Another way to explain: Fortran 90 has the INTENT(IN), INTENT(OUT),
and INTENT(INOUT) specifications for dummy arguments to indicate whether
a given dummy argument is (IN) possibly referenced but never defined;
(OUT) possibly defined but never referenced prior to an initial definition;
(INOUT) possibly defined and possibly referenced.  However, the default is
not INTENT(INOUT) as might be suspected, because a given dummy is not
necessarily known to be possible referenced and/or possibly defined at
compile time, and THAT is the default.  For a default-INTENT dummy, any
actual argument may be passed (essentially); for INTENT(INOUT), only a
definable and defined actual argument may be passed, and so on.)

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.

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).

Oh, this assumes that reporting a given invocation as violating an aliasing
requirements is not a "false" if that invocation wouldn't actually get called
during a given invocation of the program as a whole.  I.e. if one gets a
message that "CALL MATADD(A,B,B,N)" does invalid aliasing because the 3rd
argument of MATADD gets modified, it shouldn't be considered a "false" report
if the CALL itself happens to never (or rarely) get executed.  (In fact,
this is why I like compile/load-time checking, as long as it doesn't report
further levels of falses -- one gets checking that, if only performed at
run-time, might find cases one might never find by just running the program.
Cases like what happens when particular data sets are used, for example.)
--

James Craig Burley, Software Craftsperson    burley at gnu.ai.mit.edu