Now lets take a simple built.
gcc -c test1.c
gcc -c test2.c
gcc test1.o test2.o -o final
--test1.c--
/* of course in real world this would be some complex but solveable function */
int test (int a) {
a=a+1;
}
--test2.c--
#include <stdio.h>
int test(int a); /* normally in a header somewhere not bothering to
put it there */
int main() {
printf("hi value %i\n",test(20));
}
-- back to point out problem here --
Since test is in a different object file it gets completely skiped
from optimising even that it should be optimised out.
Now if you build it gcc test1.c test2.c -o final it does get optimised
out of existance.
Common argument linker should do this. Sorry that means binutils has
to have a complete duplication of the optimisation system in gcc.
Now I will run threw the information that is useful that number one
could pickup if something like this has happened number two allow
something to be done about it.
First thing is keeping two lists one of solvable functions ie
functions if passed constant values will return a constant and another
functions passed constant values that are extern. Comparing these
lists before the objects go to linker will tell if this event has
happened. Programmer can be informed and code altered avoiding events
like this. Of course this is not perfect.
This can go even more down the track. Producing two files. .o and
.solve solve contains all solvable functions. solve can be
appendable for the project. Since test1.c was built first and its
solvable was put in the solve file when test2.o is processed it is
solved. Now this makes it simpler for the linker it now only has to
strip unused functions also avoids taking a performance hit going
threw not needed code paths. Ie gcc -c test1.c -solve project.solve;
gcc -c test2.c -solve project.solve. This allows location of
solvable functions spread across many .o files. Of course this is not
perfect programmer would either have to build everything at least
twice or load them into the solve file in the correct order. Its not
a magic bullet. Of course printing warning about using functions that
could have been solved would be a good thing.
If the gcc supports import only .solve files these could be used with
libraries to reduce code as much as possible. This could be like
crypt in glibc and other functions like it that when passed constant
values give constant returns.
Even in C++ it could have major size and speed advantages.
The optimiser is missing finding functions that should be optimised
out of existence due to a minor design oversite.
Peter Dolding
