Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Whether cc after f2c can optimize arrays as well as f77 can
Message-ID: <5837@lanl.gov>
Date: 14 Nov 90 00:53:56 GMT
References: <4610:Nov1323:35:0390@kramden.acf.nyu.edu>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 56

From article <4610:Nov1323:35:0390@kramden.acf.nyu.edu>, by brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
> [...]
>   [ as another supposed counterexample, an unreadable rendition of: ]

Look who's talking.  You're the one that always flattens them out to
unreadible one-liners.

>   [ int a; main() { ... sub1(&a); } ]
>   [        sub1(x) { ... sub2(x); sub3(x); } ]
>   [ int a; sub2(y) { ... } ]
>   [ int b; sub3(z) { ... } ]
> 
> Now a and b are GLOBAL! My solution DOES detect what aliasing goes on!

Really?  I'm sorry.  I don't see it.  The method you wrote out before
will make the _same_ decision for _both_ sub2() and sub3().  The
partition in your method for sub1() is {{x}} - that's the only one.
The partitions for sub2() are either {{a}{y}} or {{a y}}.  The
partitions for sub3() are either {{a}{z}} or {{a z}}.

So, you claim that the compiler determines which versions of sub2()
and sub3() to use while it's compiling sub1().  But, why would the
compiler pick the _slow_ version of sub2() in this case?  How does
the compiler _know_ that main() is going to pass &a?  On the other
hand, why would the compiler _not_ pick the slow version of sub3()?
How does the compiler know (while working on sub1()) that main()
doesn't access b and pass &b as an argument?

> [...]
> Sorry for shouting, but I'm getting really sick of your unjustified
> attacks. If your variables have visibility as in Fortran, it *works*. If
> you're not talking about a program that can be expressed the same way in
> Fortran, then you're not talking about the same problem.

_THIS_ problem _can_ be exactly specified in Fortran.  No more hiding
behind loopholes about Fortran not (presently) having 'private' data.
This is a (vastly) simplified example of 'deep' aliasing which is very
common in large scale computing.  Unless the constraints on aliasing
are propagated through the call tree, you can't find the answers.
(Or, if you can, you certainly haven't demonstrated it yet.)

> [...]
> You are so fascinated by whatever method you think of that you are blind
> to the validity of other methods.

If you'd actually post a valid method, I'd look again.  So far, what
you've posted _won't_do_ what you claim.  The only way I can think of
for you to make this scheme work is for the function prototypes in
your header files to contain all aliasing information, not just for
the function being prototyped, but for all procedures _called_ by
the function, and all those called by them, and all those called
by them, ....  But, this is just the scheme I've been proposing
except the constraints are propagated _up_ the call chain instead
of down.

J. Giles