Comment 1 for bug 634696

This function is inlined by the early tree inliner. The compiler calculates the inlining costs as follows:

 Analyzing function body size: out_of_memory
  freq: 1000 size: 1 time: 1 D.4792 = cinfo->err;
    Likely eliminated
  freq: 1000 size: 1 time: 1 D.4792->msg_code = 54;
  freq: 1000 size: 1 time: 1 D.4792 = cinfo->err;
    Likely eliminated
  freq: 1000 size: 1 time: 1 D.4792->msg_parm.i[0] = which;
  freq: 1000 size: 1 time: 1 D.4792 = cinfo->err;
    Likely eliminated
  freq: 1000 size: 1 time: 1 D.4793 = D.4792->error_exit;
  freq: 1000 size: 2 time: 11 D.4793 (cinfo);
  freq: 1000 size: 0 time: 0 return;
    Likely eliminated
Overall function body time: 17-3 size: 8-3
With function call overhead time: 17-15 size: 8-6

In other words, it estimates the function size at 8 "units", 3 of which would likely be eliminated by inlining, and reckons a further 3 units would be eliminated from the calling function. Thus, it estimates inlining this function will cause the caller to grow by two units.

At -Os, the compiler will permit a function to grow, but only if it can eliminate the callee function entirely, and to do will not cost any more space overall. In the test case, the estimates say we save 8 units by eliminating "out_of_memory", and it costs 2 units to inline the function, so if there are 4 callers or fewer, it will do the inline.

The example code has exactly 4 callers, so the function is judged ok for inline. The problem is that the estimates are wrong - it's totally overestimated now many statements can be eliminated. In fact, the body of out_of_memory can almost be seen simply embedded within the calling functions.