low level optimization

[Jim Giles]

In article <5079 at cernvax.cern.ch>, burow at cernvax.cern.ch (burkhard burow) writes:
|> Everybody's favourite topic .....
|> 
|> jlg at cochiti.lanl.gov (Jim Giles) gives us the example 
|> [...]
|> >File3:                  File4:
|> >   extern int a;           extern int b;
|> >   func3(y)                func3(z)
           ^
Did I actually say func3 in both places?  Sorry - the one if file3
should be func2.

|> Now lets rewrite this in everybody's favourite language
|> 
|> File1:                           File2:
|>        common/puke/ia,ib
|> [...]
|> File3:                           File4:
|>        common/puke/ia,ib                common/puke/ia,ib

To be the same as the C example, there would have to be two common
blocks: one with just ia and the other with just ib.  The ia one
is common with file3, the ib one with file4.

|> [...]
|> Now I just don't get it. If the C compiler/linker/what_ever_you_call_it can't
|> optimize the nonalias in func3, and not screw up with the alias in func2,
|> what's so magical about FORTRAN? It would seem to be in the same boat.

That is exactly the point I made earlier about empowerment.  C allows
both subroutines, but most implementations pessimize both func2 and
func3 because they can't tell whether their argument is aliased to
thier global or not.  Fortran also restricts the user, but not in
speed.  The Fortran compiler optimizes both func2 and func3 as if
no aliasing has occurred - but then, the call in this example which
causes aliasing in func2 is _ILLEGAL_.  Since deliberate aliasing 
of this kind is rare (or can be made rare by coding around it), the
Fortran rule permits the user to get better code generated.  

_NEITHER_ language empowers the user to _explicitly_ ask for aliasing
or not as he pleases.  C _could_ be optimized anyway, by having a tool
that traces the identity of procedure arguments through the call tree.
The best place to do this would be the loader, which has to do call
tree analyses anyway.  Of course, the same trick would allow Fortran
to be extended to allow the call to func2 after all - the loader could
in this case _inhibit_ the optimizations that Fortran usually performs.

Without either an explicit declaration or a call chain analysis, there
is no general way I know of to optimize where it's safe to do so, and
not optimize when aliasing occurs.  Last fall, someone on comp.lang.misc
posted a method that relied on information about functions given in 
their .h files (this method would only worh for functions which _have_
.h files associated with them).  However this method *as stated* would
only find aliasing one-level deep in the call chain.  The example I
gave here would have fooled it.

|> [...]
|> QQQQuestion: The clarification I ask for above is actually a serious one, for
|> I'd like to know if with my pointer freedom in C, I can pass arguments to a
|> FORTRAN routine which will blow up, because of its optimizations based on
|> restrictions in FORTRAN.

Calling Fortran from C is safe as long as you remember not to pass pointers
to the same object (or within the same object) as two different arguments
to the Fortran routine and if you don't pass pointers to global objects
that the Fortran routine can see.  Actually, if the arguments that you
pass are not modified by the Fortran routine, it's safe to alias them.
But, it's safer not to alias anything if you can help it.

J. Giles