Bug 46176 - profile feedback causes 20% linux kernel binary growth
Summary: profile feedback causes 20% linux kernel binary growth
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-25 22:55 UTC by Andi Kleen
Modified: 2014-09-26 17:43 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andi Kleen 2010-10-25 22:55:00 UTC
Recent gcc 4.6 snapshot on x86_64-linux.

I did an experimental patch to use profile feedback with the Linux kernel
With a very simple training run (covering only ~50% of the files partially)
Unfortunately recompiling with the feedback data leads to a 20% larger
binary. This is compiled using -O2.

Trained:
   text    data     bss     dec     hex filename
13615040        1202668 1357680 16175388         f6d11c vmlinux

Untrained:
11136452        1200876 1357552 13694880         d0f7a0 vmlinux

Comparing the symbols with the largest growth I get:

add/remove: 674/2006 grow/shrink: 12172/4139 up/down: 3000900/-510189 (2490711)
function                                     old     new   delta
r600_kms_blit_copy                          2640   16394  +13754
static.do_con_write                            -   10681  +10681
r600_blit_copy                             10605   21205  +10600
zlib_inflate                                5459   15261   +9802
static.rv770_startup                           -    9541   +9541
e1000_setup_copper_link                        -    9510   +9510
e1000_diag_test                            14064   22948   +8884
kmem_cache_create                           1385   10227   +8842

I have not analyzed it in detail, but current suspicion is much
more aggressive inlining?

Note also that a lot of functions were using fallback profiling data
because the training load wasn't very good.
Comment 1 Andrew Pinski 2010-10-25 22:57:50 UTC
I think this is unrolling.  -fprofile-generate/-fprofile-use turns on unrolling.
Comment 2 Andi Kleen 2010-10-26 08:01:01 UTC
Thanks.

Unrolling seems to be part of it, but not all. I rebuilt/retrained with -fno-unroll-loops

Trained:
   text    data     bss     dec     hex filename
12774489        1198572 1357680 15330741         e9edb5 vmlinux
Untrained:
11136452        1200876 1357552 13694880         d0f7a0 ../obj-work2/vmlinux

So it's only 13% difference now, but still a lot.

function                                     old     new   delta
r600_kms_blit_copy                          2640   16394  +13754
static.do_con_write                            -   10163  +10163
static.rv770_startup                           -    9541   +9541
r600_blit_copy                             10605   19626   +9021
e1000_setup_copper_link                        -    8894   +8894
kmem_cache_create                           1385   10227   +8842
des3_ede_encrypt                            1203    8208   +7005
des3_ede_decrypt                            1203    8208   +7005
Comment 3 Andi Kleen 2010-10-26 10:28:34 UTC
Interesting tidbit: the file containing r600_kms_blit_copy -- which grew most --
didn't get any profile feedback during training, there was no data file.

I generated lists and cgraph ipa dumps for the feedback, non feedback
compilations:

dumps:
 http://halobates.de/tmp/20percent/r600_blit_kms.c.000i.cgraph-plain
 http://halobates.de/tmp/20percent/r600_blit_kms.c.000i.cgraph-feedback

listings:
 http://halobates.de/tmp/20percent/r600_blit_kms.lst-plain
 http://halobates.de/tmp/20percent/r600_blit_kms.lst-feedback
Comment 4 Andi Kleen 2014-09-26 17:43:04 UTC
I think this were broken profile feedback files.

I'll reopen if it happens again.