G++不能内联多态方法？

经过优化的g++似乎不能内联来自翻译单元静态变量的简单函数调用。代码和编译后的输出示例如下。注意函数can_inline_local通过使用DerivedType的本地实例完美地内联调用，然而cant_inline_static是一个相当长的呼叫。

在你因为我的过早优化而报警之前，我想为自己辩护一下，多态继承将非常清楚地描述我的内核级串行驱动程序中断服务例程。如果c++可以为我内联虚拟调用(使用我认为它在编译时应该知道的东西)，那么我就会有清晰的可测试代码，编译成C的性能。

我正在使用arm-none-eabi-g++ -vGCC version 4.9.3 20150529 (prerelease) (15:4.9.3+svn227297-1)

arm-none-eabi-g gnu + + + +化11 o3 - c - o内联。p &&arm-none-eabi-objdump内联。0 -S> inline.dump

inline.cpp:

extern "C"{
int * const MEMORY_MAPPED_IO_A = (int*)0x40001000;
int * const MEMORY_MAPPED_IO_B = (int*)0x40002000;
}
namespace{
/** Anon namespace should make these
typedefs static to this translation unit */
struct BaseType{
void* data;
virtual void VirtualMethod(int parameter){
*MEMORY_MAPPED_IO_A = parameter;
}
void VirtualCaller(int parameter){
this->VirtualMethod(parameter);
}
};
struct DerivedType : BaseType{
void VirtualMethod(int parameter) final {
*MEMORY_MAPPED_IO_B = parameter;
}
};
/** static keyword here may be superfluous */
static BaseType basetype;
static DerivedType derivedtype;
extern "C"{
void cant_inline_static(int parameter){
derivedtype.VirtualCaller(1);
}
void can_inline_local(int parameter){
DerivedType localobj;
localobj.VirtualCaller(1);
}
}
}

inline.dump

inline.o:     file format elf32-littlearm

Disassembly of section .text:
00000000 <_ZN12_GLOBAL__N_18BaseType13VirtualMethodEi>:
0:   e59f3004    ldr r3, [pc, #4]    ; c <_ZN12_GLOBAL__N_18BaseType13VirtualMethodEi+0xc>
4:   e5831000    str r1, [r3]
8:   e12fff1e    bx  lr
c:   40001000    .word   0x40001000
00000010 <_ZN12_GLOBAL__N_111DerivedType13VirtualMethodEi>:
10:   e59f3004    ldr r3, [pc, #4]    ; 1c <_ZN12_GLOBAL__N_111DerivedType13VirtualMethodEi+0xc>
14:   e5831000    str r1, [r3]
18:   e12fff1e    bx  lr
1c:   40002000    .word   0x40002000
00000020 <cant_inline_static>:
20:   e59f0028    ldr r0, [pc, #40]   ; 50 <cant_inline_static+0x30>
24:   e5903000    ldr r3, [r0]
28:   e59f2024    ldr r2, [pc, #36]   ; 54 <cant_inline_static+0x34>
2c:   e5933000    ldr r3, [r3]
30:   e1530002    cmp r3, r2
34:   1a000003    bne 48 <cant_inline_static+0x28>
38:   e3a02001    mov r2, #1
3c:   e59f3014    ldr r3, [pc, #20]   ; 58 <cant_inline_static+0x38>
40:   e5832000    str r2, [r3]
44:   e12fff1e    bx  lr
48:   e3a01001    mov r1, #1
4c:   e12fff13    bx  r3
...
58:   40002000    .word   0x40002000
0000005c <can_inline_local>:
5c:   e3a02001    mov r2, #1
60:   e59f3004    ldr r3, [pc, #4]    ; 6c <can_inline_local+0x10>
64:   e5832000    str r2, [r3]
68:   e12fff1e    bx  lr
6c:   40002000    .word   0x40002000
Disassembly of section .text.startup:
00000000 <_GLOBAL__sub_I_cant_inline_static>:
0:   e59f3014    ldr r3, [pc, #20]   ; 1c <_GLOBAL__sub_I_cant_inline_static+0x1c>
4:   e59f2014    ldr r2, [pc, #20]   ; 20 <_GLOBAL__sub_I_cant_inline_static+0x20>
8:   e2831008    add r1, r3, #8
c:   e2833018    add r3, r3, #24
10:   e5821008    str r1, [r2, #8]
14:   e5823000    str r3, [r2]
18:   e12fff1e    bx  lr
...

简单地注释掉void* data;字段允许对琐碎的虚拟调用进行积极的优化。下面是objdump。如果类具有可能未初始化的数据成员，那么c++可能不信任使用静态实例方法。是否有任何方法可以指定一个类是它看起来的样子，不需要构造或初始化?如果编译器假设这些事情，所有的c++会因为一些我不知道的过度设计/深奥的功能而无效吗?我觉得我是在抓救命稻草，但值得再问一次。

inline.o:     file format elf32-littlearm

Disassembly of section .text.cant_inline_static:
00000000 <cant_inline_static>:
0:    2201        movs    r2, #1
2:    4b01        ldr r3, [pc, #4]    ; (8 <cant_inline_static+0x8>)
4:    601a        str r2, [r3, #0]
6:    4770        bx  lr
8:    40002000    .word   0x40002000
Disassembly of section .text.can_inline_local:
00000000 <can_inline_local>:
0:    2201        movs    r2, #1
2:    4b01        ldr r3, [pc, #4]    ; (8 <cant_inline_static+0x8>)
4:    601a        str r2, [r3, #0]
6:    4770        bx  lr
8:    40002000    .word   0x40002000

最终更新

我已经算出了在cant_inline_static开头出现的记账代码。它只是取静态实例derivedtype，取消引用它的虚值表，查找VirtualMethod条目，然后将其与derivedtype::VirtualMethod的.text地址进行比较。如果匹配，则运行内联过程。如果它们不相同，则调用实例的vtable方法。

似乎g++希望虚拟调用最终是DerivedType::VirtualMethod，但它担心静态DerivedType变量的虚表可能指向不同的方法。如果你初始化了DerivedType的所有成员(和继承的成员)变量，那么g++就获得了完全内联'VirtualMethod'所需的信心。正如@rici解释的那样，这很可能与'derivedtype'实例被放置在.data(显式初始化)而不是.bss有关。

一个有趣的补充点:如果派生类型和基类型实例都调用VirtualCaller，那么无论成员初始化如何，g++都会添加记账代码。

在这一点上，我扮演考古学家的角色，发现一些家伙是如何编写g++优化器的这一部分的。这是一次有趣的旅行。我在这里得到了很好的帮助。在这个过程中，我学到了很多关于虚拟方法性能的知识。

struct S {
int one = 1;
int zeros[1000000] = {0};
};
S s;

struct S {
int one = 1;
int zeros[1000000];
};
S s;

derivedtype.DerivedType::VirtualMethod(p);

((DerivedType)nullptr)->DerivedType::VirtualMethod(p);

((decltype(derivedtype)*)(nullptr)->decltype(derivedtype)::VirtualMethod(p);

e3a02001    mov r2, #1         ; put 1 to register r2
e59f3014    ldr r3, [pc, #20]  ; put address 0x40002000 to r3
e5832000    str r2, [r3]       ; store value of r1 to adress in r3