1 |
-- Sven Vermeulen <swift@g.o> spake thusly: |
2 |
|
3 |
> On Sat, May 17, 2003 at 03:49:11AM +0100, Chris Davies wrote: |
4 |
>> I had the idea to build -fbranch-probabilities optimisation into |
5 |
>> portage. This is where a sample run of data is taken using the |
6 |
>> program compiled with -fprofile-arcs, and that data then used to |
7 |
>> reorganise the object code so conditional branches are layed out in |
8 |
>> a more efficient manner. |
9 |
> |
10 |
> Why implement it in Portage? Isn't it up to the user to define it in |
11 |
> the CFLAGS or not? |
12 |
|
13 |
This isn't a simple matter of turning on a compiler flag. |
14 |
|
15 |
>From 'man gcc': |
16 |
|
17 |
After running a program compiled with -fprofile-arcs, you can |
18 |
compile it a second time using -fbranch-probabilities, to |
19 |
improve optimizations based on the number of times each branch |
20 |
was taken. When the program compiled with -fprofile-arcs exits |
21 |
it saves arc execution counts to a file called sourcename.da for |
22 |
each source file The information in this data file is very |
23 |
dependent on the structure of the generated code, so you must |
24 |
use the same source code and the same optimization options for |
25 |
both compilations. |
26 |
|
27 |
However, the problem with trying to integrate this into portage is that |
28 |
it must either: |
29 |
|
30 |
1) Compile programs on the user's machine, allow the user to run |
31 |
them, and then rebuild using the generated data. Quite a |
32 |
lengthy process, and fraught with issues. |
33 |
|
34 |
or |
35 |
|
36 |
2) Distribute the profile data along with the source code. The |
37 |
trouble with this is that (as the man page says) it requires |
38 |
using the same source code and optimization options. So not only |
39 |
must the CFLAGS used be the same as with the profiled code, but |
40 |
the configure settings (which alter #define's and therefore the |
41 |
source) must be the same as well. |
42 |
|
43 |
|
44 |
-- |
45 |
gentoo-dev@g.o mailing list |