Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!ai-lab!life!burley From: burley@pogo.gnu.ai.mit.edu (Craig Burley) Newsgroups: comp.lang.c Subject: Re: low level optimization Message-ID: Date: 1 May 91 19:30:42 GMT References: <1991Apr17.225944.15261@zoo.toronto.edu> <22839@lanl.gov> <5475@goanna.cs.rmit.oz.au> <22983@lanl.gov> Sender: news@ai.mit.edu Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139 Lines: 59 In-reply-to: jlg@cochiti.lanl.gov's message of 1 May 91 16:05:57 GMT In article <22983@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes: In article <5475@goanna.cs.rmit.oz.au>, ok@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@gnu.ai.mit.edu