Bug #10080: Functions marked as "static inline" are not inlined by gcc

• Status: Rejected
• Assignee: nobu (Nobuyoshi Nakada)
• Target version: -
• ruby -v: ruby 2.1.2p95 (2014-05-08 revision 45877)
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN

[gustavo.pedrosa (Gustavo Frederico Temple Pedrosa)]

Since GCC 4.8.3, some static inline functions (such as rb_call0) are not
inlined in the generated machine code. This happens in both x86-64 and ppc64
platforms and it can be verified by using the following commands:

(in ppc64)

 objdump -dS ruby | grep bl.*rb_call0

   155838:       c1 f8 ff 4b     bl      1550f8 <rb_call0+0x8>
   1558a4:       55 f8 ff 4b     bl      1550f8 <rb_call0+0x8>
   1559e4:       15 f7 ff 4b     bl      1550f8 <rb_call0+0x8>
   158b88:       71 c5 ff 4b     bl      1550f8 <rb_call0+0x8>
   15bf40:       b9 91 ff 4b     bl      1550f8 <rb_call0+0x8>
   15c0f8:       01 90 ff 4b     bl      1550f8 <rb_call0+0x8>
   15c490:       69 8c ff 4b     bl      1550f8 <rb_call0+0x8>
   15c4cc:       2d 8c ff 4b     bl      1550f8 <rb_call0+0x8>
   15c8bc:       3d 88 ff 4b     bl      1550f8 <rb_call0+0x8>
   15cc94:       65 84 ff 4b     bl      1550f8 <rb_call0+0x8>
   15d344:       b5 7d ff 4b     bl      1550f8 <rb_call0+0x8>
   15d3c4:       35 7d ff 4b     bl      1550f8 <rb_call0+0x8>
   
(in x86-64)
  
 objdump -dS ruby | grep call\.*rb_call0
  
   126280:       e8 cb f9 ff ff          callq  125c50 <rb_call0>
   126347:       e8 04 f9 ff ff          callq  125c50 <rb_call0>
   1264cc:       e8 7f f7 ff ff          callq  125c50 <rb_call0>
   128a9e:       e8 ad d1 ff ff          callq  125c50 <rb_call0>
   12ade9:       e8 62 ae ff ff          callq  125c50 <rb_call0>
   12af6a:       e8 e1 ac ff ff          callq  125c50 <rb_call0>
   12b2e6:       e8 65 a9 ff ff          callq  125c50 <rb_call0>
   12b5d7:       e8 74 a6 ff ff          callq  125c50 <rb_call0>
   12b899:       e8 b2 a3 ff ff          callq  125c50 <rb_call0>
   12bccd:       e8 7e 9f ff ff          callq  125c50 <rb_call0>
   12bdf0:       e8 5b 9e ff ff          callq  125c50 <rb_call0>

This behaviour can be fixed if every inlined function were marked with the always_inline attribute when compiling with GCC.

[normalperson (Eric Wong)]

Can you show a performance difference with always_inline on those
functions?

Inlining is not always faster, it bloats the code and eats cache.
Perhaps GCC is avoiding that bloat.

[gustavo.pedrosa (Gustavo Frederico Temple Pedrosa)]

Eric Wong wrote:

Can you show a performance difference with always_inline on those
functions?

Inlining is not always faster, it bloats the code and eats cache.
Perhaps GCC is avoiding that bloat.

Sorry, yes, you are right. There is a small performance penalty when
every function marked as inline is, in fact, inlined. There are other
issues, a lot of functions are not being inlined because GCC cannot
do that or because they imply in code bloating (as detected by the
compiler heuristics). Do you think it would be interesting to remove
the inline keyword in such cases?

[ko1 (Koichi Sasada)]

(2014/07/23 1:31), [e-mail] wrote:

Do you think it would be interesting to remove
the inline keyword in such cases?

Why remove them?

--
// SASADA Koichi at atdot dot net

[normalperson (Eric Wong)]

I don't think removing "inline" is necessary, either. It is a hint
to the compiler (and as evidenced, your compiler is capable of
ignoring it). Different compilers may still inline it and produce
faster code.

[gustavo.pedrosa (Gustavo Frederico Temple Pedrosa)]

Eric Wong wrote:

I don't think removing "inline" is necessary, either. It is a hint
to the compiler (and as evidenced, your compiler is capable of
ignoring it). Different compilers may still inline it and produce
faster code.

Yes, you are right.
So, can I close this issue?

[normalperson (Eric Wong)]

[e-mail] wrote:

So, can I close this issue?

Sure.

[gustavo.pedrosa (Gustavo Frederico Temple Pedrosa)]

Eric Wong wrote:

[e-mail] wrote:

So, can I close this issue?

Sure.

I don't have permissions to close, can you close for me, please?
Thank you very much, indeed.

[normalperson (Eric Wong)]

• Description updated (diff)
• Status changed from Open to Rejected