Paolo Bonzini wrote:
> > But the compiler does not know that fstrcmp is called millions of time and
> > that this piece of code needs to be optimized for speed rather than for
> > space.
>
> If doing profile-directed optimization, it does know.
However, it is impractical: I never used profile-directed optimization with
GCC so far, because the steps to put it in place are prohibitive. In a
just-in-time compiler, such as in Java or C# virtual machines, it can be
implemented transparently. But in a C compiler, it requires the following
steps (taken from the GCC manual):
* Compile the source files with `-fprofile-arcs' plus
optimization and code generation options.
* Link your object files with `-lgcov' or `-fprofile-arcs' (the
latter implies the former).
* Run the program on a representative workload to generate the
arc profile information.
* Compile the source files again with the same optimization and
code generation options plus `-fbranch-probabilities'
How can these steps easily be implemented in a package which has its source
in one subdirectory and its tests in another subdirectory? In a typical
autoconf/automake based setup, "make" recurses first into the sources directory
and then into the tests directory - and never into the sources directory again.
The emphasis is on "easily". With enough hacks to the build infrastructure of
a package, I can achieve anything. But I won't make my Makefile.ams
unmaintainable for the gain of just a few percent of performance. If automake
would offer an option that keeps the Makefile.ams simple, things would be
different.
Bruno
