low level optimization

[burkhard burow]

Everybody's favourite topic .....

jlg at cochiti.lanl.gov (Jim Giles) gives us the example 

>I'll show you what needs to be done, you show me how the it can be
>done without interprocedural analysis.
>
>File1:                  File2:
>   int a, b;               func1(x)
>   main (){                int *x;
>   ...                     {
>      func1(&a)                func2(x); func3(x);  
>   ...                      ...
>   }                       }
>
>File3:                  File4:
>   extern int a;           extern int b;
>   func3(y)                func3(z)
>   int *y;                 int *z
>   {                       {
>      expression(a,y);         expression(b,z};
>   }                       }
>

Now lets rewrite this in everybody's favourite language

File1:                           File2:
       common/puke/ia,ib
       program demo                    func1(ix)
          ....                           ....
       call func1(ia)                  call func2(ix)
          ...                          call func3(ix)
       end                              ...
                                       end

File3:                           File4:
       common/puke/ia,ib                common/puke/ia,ib
       func2(iy)                        func3(iz)
       expression with ia,iy            expression with ib,iy
       end                              end

Don't laugh, this little bit of FORTRAN almost killed me.
And as with the original posting, we're all going to ignore little syntax
errors that may have creeped in.

Now jlg at cochiti.lanl.gov (Jim Giles) gave this challenge:

>These four files are separately compiled.  If loaded together, they will
>produce a program in which y and a are aliased in func2(); also b and z
>will _not_ be aliased in func3() (because z is really a pointer to a).
>Now, the optimization I want is for the final code to optimize func3()
>as much as possible since there is no aliasing.  But, the solution must
>also inhibit unsafe optimizations in func2() because there _is_ aliasing.

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.

I fear that I'm on the wrong side of ignorance, so I would appreciate an
explanation.

A bit o' irelevant background:
I must admit that I care much more about the programmers performance (mainly
me!) than I do about the machines performance. I'm a C hack swimming in a
FORTRAN world. To keep me from drowning I've created created CFORTRAN, a set of
macros that 'prototype' FORTRAN functions. e.g.

When my friends do:
      CALL HBOOK1(1,'pT spectrum of pi+',100,0.,5.,0.)
I can do:
           HBOOK1(1,"pT spectrum of pi+",100,0.,5.,0.);

after I've 'prototyped' the FORTRAN function:
PROTOCCALLSFSUB6(hbook1,INT,STRING,INT,FLOAT,FLOAT,FLOAT)
#define HBOOK1(ID,CHTITLE,NX,XMI,XMA,VMX)                 \
     CCALLSFSUB6(hbook1,INT,STRING,INT,FLOAT,FLOAT,FLOAT, \
               ID,CHTITLE,NX,XMI,XMA,VMX) 

I create the prototypes (about 20 FORTRAN routines per hour, main bottleneck is
my typing speed) using info. from the FORTRAN routines' documentation. i.e. My
C code  uses 'FORTRAN' object code, without me ever looking at, or dealing with
a single line of FORTRAN source code. 

I've got CFORTRAN running, i.e. I've created a cfortran.h file with the
preprocessor directives, on RISC Mips (e.g. Silicon Graphics, DECstations) and
VAX VMS machines. I'm still trying to sell the idea to the world, but have
already generated some bootstrap interest. If you're curious, send mail.

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.

QQQQuestion: Lots of manuals have little sections on calling and linking
different languages within the same program. How many people out there actually
do this sort of thing? e.g. How many people out there use C, handling the messy
jobs of i/o, user interface, etc., as a frontend to number crunching FORTRAN
routines? It doesn't matter whether you call the FORTRAN routines because of
performance reasons, or as in my case, because they exist and work.

hoping somebody reads this line.
burkhard                          burow%13313.hepnet at csa3.lbl.gov