On Wed, 16 Jul 2008, Ralf Wildenhues wrote:
execution. Is this within the realm of possibility for future Automake?
No idea. How are you doing it now?
I am not doing it now, but an example of its successful use is in the
GCC build when built via 'make profiledbootstrap'. For the last
several years I have been building GCC this way even though it is
much slower to build.
Automake isn't magic, it can automate (sorry for the pun) some work
flows if they are sufficiently easy to generalize. The first step
in doing so is typically showing how things work manually.
Right.
It seems that for the first pass, the code is compiled with additional
options `-fprofile-generate' and optimization disabled. After the
code is executed to produce '.gcno' and '.gcda' files, the
`-fprofile-use' option is used to make use of the profile data while
optimizing the program. The profile data is useful since the most
commonly executed code paths are placed first, with seldom executed
paths (e.g. error handlers or strange cases) getting less priority.
Otherwise some branch-heavy algorithms are poorly optimized since the
compiler can not sufficiently guess the critical paths and does not
know the ideal order to peform branching tests.
In order to obtain a good set of profile data files, the test
program(s?) need to exercise the important aspects of the program with
typical data.
Based on results posted by others, it seems that profiled code is 8%
(e.g. GCC) or 15% (e.g. lame) or even 50% faster.
As an implementation in automake, a new top target can be added which
builds the program, executes a user-provided test program (similar to
'check') to collect profile data, cleans the objects, and then builds
the optimized version. There is also the option of coming up with a
naming scheme so that the built objects instrumented for profiling can
live in the same build tree as the final objects.
This forum topic seems pretty interesting:
http://www.gp32x.com/board/index.php?showtopic=28490&st=15
Bob
