[Bug tree-optimization/57218] [4.8/4.9 Regression] Excessive inlining even at -Os

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57218

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-05-10
                 CC|                            |hubicka at gcc dot gnu.org
   Target Milestone|---                         |4.8.1
            Summary|Excessive inlining even at  |[4.8/4.9 Regression]
                   |-Os                         |Excessive inlining even at
                   |                            |-Os
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

Deciding on inlining of small functions.  Starting with size 47.
Enqueueing calls of std.isra.0/8.
   Estimating body: std.isra.0/8
   Known to be false: not inlined, op1 changed, op2 changed
   size:11 time:20
   Estimating body: std.isra.0/8
   Known to be false: not inlined, op1 changed, op2 changed
   size:11 time:20
   Estimating body: std.isra.0/8
   Known to be false: not inlined, op1 changed, op2 changed
   size:11 time:20
  enqueuing call __sinit/1 -> std.isra.0/8, badness -36092160
  enqueuing call __sinit/1 -> std.isra.0/8, badness -36092160
  enqueuing call __sinit/1 -> std.isra.0/8, badness -36092160
Enqueueing calls of __sinit/1.
   Estimating body: std.isra.0/8
   Known to be false: not inlined, op1 changed, op2 changed
   size:11 time:20

Considering std.isra.0 with 21 size
 to be inlined into __sinit in newlib/libc/stdio/findfp.c:79
 Estimated growth after inlined into all is +0 insns.
 Estimated badness is -36092160, frequency 0.39.
    Badness calculation for __sinit/1 -> std.isra.0/8
      size growth 7, time 20  big_speedup
      -36092160: guessed profile. frequency 0.389000, benefit 23.529411%, time
w/o inlining 34, time w inlining 26 overall growth 0 (current) 0 (original)
                Accounting size:7.00, time:2.72 on predicate:(op0[ref offset:
640] == 0)
Processing frequency std.isra.0
  Called by __sinit that is normal or hot
 Inlined into __sinit which now has time 26 and size 33,net change of +7.


So the reason is that it can eliminate the body of 'std' after inlining
it three times and it computes that the cost of doing that (3 * 7 is
the same as the cost of the offline body).

And that's because

  ptr_1(D)->_p = 0B;
                freq:1.00 size:  1 time:  1
                50% will be eliminated by inlining
                Accounting size:0.50, time:0.50 on predicate:(not inlined)
                Accounting size:0.50, time:0.50 on predicate:(true)
  ptr_1(D)->_r = 0;
                freq:1.00 size:  1 time:  1
                50% will be eliminated by inlining
                Accounting size:0.50, time:0.50 on predicate:(not inlined)
                Accounting size:0.50, time:0.50 on predicate:(true)
...

the inliner thinks that it is likely that initializations via parameters
are eliminated by inlining:

Inline summary for std.isra.0/8 inlinable
  self time:       29
  global time:     0
  self size:       21
  global size:     0
  self stack:      0
  global stack:    0
    size:7.000000, time:7.000000, predicate:(true)
    size:10.000000, time:9.000000, predicate:(not inlined)
  calls:
    memset/3 function body not available
      loop depth: 0 freq:1000 size: 4 time: 13 callee size: 0 stack: 0
       op1 is compile time invariant
       op2 is compile time invariant

not sure why we have that (not inlined) predicate size stuff but use
'self size' when accounting against inlining multiple times.

The above seems to suggest that GCC will _always_ inline a function
with just initializers twice when the body can be eliminated then.