Re: profile-directed optimization

[Bruno Haible]

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