low level optimization
Jim Giles
jlg at cochiti.lanl.gov
Sat Apr 27 09:24:15 AEST 1991
In article <RJC.91Apr25134502 at brodie.cstr.ed.ac.uk>, rjc at cstr.ed.ac.uk (Richard Caley) writes:
|> [...]
|> No, you said the `linker' would have to do code analysis and code
|> generation, I said it would have to make a choice. If the difference
|> is not clear, I suggest you try and code them. How big do you think
|> interprocedureal analysis plus code generation is? I think it is clear
|> that choosing one of two sets of definitions takes about 100 including
|> totally paranoid levels of defensive tests.
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};
} }
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, you show me your specific solution and then we'll be able to decide
whether it works, whether it is standard conforming, whether is generalizes
to more than one arg/global, and whether it does interprocedural analysis
or not.
|> [...]
|> jg> The load-time tool actually does the interprocedural analysis.
|>
|> Nope, it doesn't even need to know that the difference between the
|> alternate definitions _is_ interprocedural analysis.
If the method you are proposing manages the above example correctly,
then the choice the load-time tool _is_ intermodular analysis. Whether
it "knows" it or not is an irrelevant point. I don't think that any
program yet written can be said to _know_ anything.
J. Giles
More information about the Comp.lang.c
mailing list