为什么MSVC编译器/优化器不消除共享库内重复函数调用反而复制函数体

核心原因 #

这个现象是共享库默认的符号可见性与运行时替换规则限制，既不是语言设计缺陷，也不是编译器优化能力不足：
默认情况下，所有从动态库导出的符号都支持运行时替换（比如Windows的DLL重定向、Linux的LD_PRELOAD机制），编译器/链接器必须保守处理，不能主动将导出的bar优化为foo的别名，也不能让宿主直接跳过bar调用foo，否则会破坏依赖符号替换的合法场景。
你观察到DLL内的bar直接复制了foo的函数体，是因为MSVC在开启优化时会自动内联体积足够小的函数，只要把foo的实现改得更复杂，bar就会生成jmp TestClass::foo的跳板代码，不会再重复生成完整函数体。

问题1：是否可通过编译选项开启合规优化？ #

可以，优化方案完全符合ABI规范，无兼容性风险：

• 针对Windows平台MSVC：链接时添加 /OPT:ICF 选项（相同COMDAT折叠），该选项会自动将机器码完全一致的函数合并为同一个地址，你场景中的bar和foo优化后机器码完全相同，开了该选项后导出表中两个符号的地址会完全一致，和你期望的效果完全相同。
• 针对Linux平台GCC/Clang：编译时添加 -fno-semantic-interposition 选项关闭符号插入允许，链接时添加 -flto + --icf=all 选项，也能实现相同的函数折叠效果。
  以上优化都不需要修改代码，完全符合ABI规范，仅会禁用你大概率用不到的运行时符号替换功能。

问题2：是否为MSVC特有行为？ #

不是，GCC、LLVM默认配置下都有相同的行为。
所有主流编译器的默认配置都会遵循动态链接的符号插入规则，不会主动做跨模块的透传函数优化、相同函数合并，避免破坏运行时替换的兼容性。

C/C++兼容API封装的最优实践 #

可以同时兼顾C和C++宿主的性能：

1. 先开启上述的ICF类优化，保证所有宿主调用bar的开销和直接调用foo完全一致。
2. 额外在公开头文件中为C++宿主提供bar的inline实现，用宏判断编译环境：

#ifdef __cplusplus
inline int bar(TestClass* fooClass, int a, int b, int c) {
    return fooClass->foo(a, b, c);
}
#endif

C++宿主会直接内联掉bar的调用，C宿主看不到inline实现，还是调用动态库中的bar，两边都能拿到最优性能。
3. 如果追求极致可控，可以手动实现bar为汇编跳板，直接跳转至foo的地址，开销可以忽略不计，且不受编译器优化选项影响。

内容的提问来源于stack exchange，提问作者endyx