Jan Hubicka wrote:

-fno-ipa-cp should work around your problem for time being.

Indeed it did. Some figures:

hlprog (the main forecast program):

link time optimization time: 3:20 minutes
top memory usage:            920  Mbyte

Inliner report:

Inlined 764 calls, eliminated 226 functions, size 260368 turned to 126882 size.

hirvda (the observation usage program):

link time optimization time: 10:05 minutes
top memory usage:            2.3 Gbyte

Inliner report:

Inlined 2518 calls, eliminated 608 functions, size 1187204 turned to 705838 size.

Of course, there still is:

Considering invlo6 size 1996.
 Called once from lowpass 530 insns.
Inlined into lowpass which now has 2293 size for a net change of -2229 size.

Considering invlo4 size 1462.
 Called once from lowpass 2293 insns.
 Not inlined because --param large-function-growth limit reached.

Considering invlo2 size 933.
 Called once from lowpass 2293 insns.
 Not inlined because --param large-function-growth limit reached.

where the largest callee *does* get inlined, while two smaller ones don't (I agree with Jan that this would have been solved by training the inliner with profiling data, because only invlo4 gets called).

However, my endeavour is to boldly go where no inliner has gone before, and implement -falways-inline-functions-only-called-once, along the following lines:

$ svn diff ipa-inline.c
Index: ipa-inline.c
===================================================================
--- ipa-inline.c        (revision 153776)
+++ ipa-inline.c        (working copy)
@@ -1246,7 +1246,7 @@
                           node->callers->caller->global.size);
                }

-             if (cgraph_check_inline_limits (node->callers->caller, node,
+ if (1 || cgraph_check_inline_limits (node->callers->caller, node,
                                              &reason, false))
                {
                  cgraph_mark_inline (node->callers);

(Sugg. b. Rich. G.), because inlining functions that are only called once is always profitable (in number of instructions saved).

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html

Reply via email to