[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Profiled-arc builds?
Re: Profiled-arc builds?
Wed, 16 Jul 2008 21:13:33 +0200
* Bob Friesenhahn wrote on Wed, Jul 16, 2008 at 05:01:28PM CEST:
> 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
Yes, this is how it works in GCC: stage2 is compiled with
-fprofile-generate, stage3 is compiled with -fprofile-use.
Before stage3 is compiled, the profile output files are
linked or copied around to be in place for use.
GCC is special in that the compiled programs are used to
compile (themselves) in a later stage.
>> 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.
You could help by doing this manually for your package, from beginning
to end, once. Keep a log of the commands you use. Try to generalize
those commands to other packages. Post the resulting logs.
> 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
Yes; this much I knew from using them at one point in the past.
Here's some things I don't know, and where I would start off
- assume first that 'make check' generates typical program execution.
- start with this command sequence:
./configure "CFLAGS=-g -fprofile-generate"
make all check
./configure "CFLAGS=-g -fprofile-use"
make clean all check
What's necessary to make this sequence do something useful?
Which parts need to be adjusted for packages? What about VPATH
builds? What about VPATH builds which used an absolute path for
the configure script?
> The profile data is useful since the most commonly executed
> code paths are placed first, [...]
Yes, I don't think anybody questions the usefulness of profiling.
I am lacking the free time to fill in the technical details above,
if they are sorted out we can still start looking at whether and
how Automake can help here.
> 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.
First, I think it's too early to ponder such issues, second, typically
Automake encourages to use separate build trees for separate build
options. Also, new targets aren't added lightly (they always create
a backwards incompatibility, and bloat), so usefulness and viability
should be proved first.