我不确定你的说法：
较小的函数会被优化器自动“内联”，而不管是否提到内联。很明显，使用关键字inline，用户对函数“内联”没有任何控制权。
我听说编译器可以随意忽略你的inline请求，但我不认为他们会完全忽略它。
我查看了Github存储库中的Clang和LLVM。（谢谢开源软件！））我发现**inline关键字 * 确实 * 让Clang/LLVM更有可能内联函数。**

搜索

在the Clang repository中搜索单词inline会找到标记说明符kw_inline。看起来Clang使用了一个聪明的基于宏的系统来构建lexer和其他关键字相关的函数，所以没有像if (tokenString == "inline") return kw_inline这样的直接函数。但是在ParseDecl.cpp中，我们看到kw_inline导致对DeclSpec::setFunctionSpecInline()的调用。

case tok::kw_inline:
  isInvalid = DS.setFunctionSpecInline(Loc, PrevSpec, DiagID);
  break;

在该函数中，我们设置一个位，如果它是一个重复的inline，则发出警告：

if (FS_inline_specified) {
  DiagID = diag::warn_duplicate_declspec;
  PrevSpec = "inline";
  return true;
}
FS_inline_specified = true;
FS_inlineLoc = Loc;
return false;

在其他地方搜索FS_inline_specified，我们看到它是位域中的一个位，它被用于getter函数isInlineSpecified()：

bool isInlineSpecified() const {
  return FS_inline_specified | FS_forceinline_specified;
}

搜索isInlineSpecified()的调用站点，我们找到了codegen，在那里我们将C++解析树转换为LLVM中间表示：

if (!CGM.getCodeGenOpts().NoInline) {
  for (auto RI : FD->redecls())
    if (RI->isInlineSpecified()) {
      Fn->addFnAttr(llvm::Attribute::InlineHint);
      break;
    }
} else if (!FD->hasAttr<AlwaysInlineAttr>())
  Fn->addFnAttr(llvm::Attribute::NoInline);

Clang到LLVM

我们完成了C++解析阶段。现在我们的inline说明符被转换为语言中立的LLVM Function对象的属性。我们从Clang切换到the LLVM repository。
搜索llvm::Attribute::InlineHint得到方法Inliner::getInlineThreshold(CallSite CS)（带有一个看起来很可怕的无括号if块）：

// Listen to the inlinehint attribute when it would increase the threshold
// and the caller does not need to minimize its size.
Function *Callee = CS.getCalledFunction();
bool InlineHint = Callee && !Callee->isDeclaration() &&
  Callee->getAttributes().hasAttribute(AttributeSet::FunctionIndex,
                                       Attribute::InlineHint);
if (InlineHint && HintThreshold > thres
    && !Caller->getAttributes().hasAttribute(AttributeSet::FunctionIndex,
                                             Attribute::MinSize))
  thres = HintThreshold;

所以我们已经有了一个来自优化级别和其他因素的基线内联阈值，但是如果它低于全局HintThreshold，我们就把它提高。* （提示阈值可从命令行设置。）*
getInlineThreshold()似乎只有一个调用站点，是SimpleInliner的成员：

InlineCost getInlineCost(CallSite CS) override {
  return ICA->getInlineCost(CS, getInlineThreshold(CS));
}

它在指向InlineCostAnalysis示例的成员指针上调用一个虚拟方法，也称为getInlineCost。
搜索::getInlineCost()以查找类成员的版本，我们发现一个是AlwaysInline的成员-这是一个非标准但广泛支持的编译器特性-另一个是InlineCostAnalysis的成员。它在这里使用它的Threshold参数：

CallAnalyzer CA(Callee->getDataLayout(), *TTI, AT, *Callee, Threshold);
bool ShouldInline = CA.analyzeCall(CS);

CallAnalyzer::analyzeCall()超过200行，并做了决定函数是否可内联的真实的实质性工作。它权衡了许多因素，但当我们阅读该方法时，我们看到它的所有计算都操纵Threshold或Cost。最后：

return Cost < Threshold;

但是名为ShouldInline的返回值实际上是用词不当。实际上，analyzeCall()的主要目的是在CallAnalyzer对象上设置Cost和Threshold成员变量。返回值仅指示当其他因素覆盖成本与阈值分析时的情况，如我们在这里看到的：

// Check if there was a reason to force inlining or no inlining.
if (!ShouldInline && CA.getCost() < CA.getThreshold())
  return InlineCost::getNever();
if (ShouldInline && CA.getCost() >= CA.getThreshold())
  return InlineCost::getAlways();

否则，我们返回一个存储Cost和Threshold的对象。

return llvm::InlineCost::get(CA.getCost(), CA.getThreshold());

所以在大多数情况下，我们不会返回一个是或否的决定。搜索继续！getInlineCost()的返回值在哪里使用？

真实的决定

在bool Inliner::shouldInline(CallSite CS)中找到。另一个大功能。它一开始就调用getInlineCost()。
结果是getInlineCost分析了内联函数的 * 内在 * 成本--其参数签名、代码长度、递归、分支、链接等。- 和一些关于 * 每个 * 使用该函数的地方的聚合信息。另一方面，shouldInline()将此信息与有关使用该函数的 * 特定 * 位置的更多数据相结合。
在整个方法中，有对InlineCost::costDelta()的调用-它将使用analyzeCall()计算的InlineCost s Threshold值。最后，我们返回一个bool。已经决定了。在Inliner::runOnSCC()中：

if (!shouldInline(CS)) {
  emitOptimizationRemarkMissed(CallerCtx, DEBUG_TYPE, *Caller, DLoc,
                               Twine(Callee->getName() +
                                     " will not be inlined into " +
                                     Caller->getName()));
  continue;
}

// Attempt to inline the function.
if (!InlineCallIfPossible(CS, InlineInfo, InlinedArrayAllocas,
                          InlineHistoryID, InsertLifetime, DL)) {
  emitOptimizationRemarkMissed(CallerCtx, DEBUG_TYPE, *Caller, DLoc,
                               Twine(Callee->getName() +
                                     " will not be inlined into " +
                                     Caller->getName()));
  continue;
}
++NumInlined;

InlineCallIfPossible()根据shouldInline()的决定进行内联。
因此Threshold受到inline关键字的影响，并在最后决定是否内联。
因此，您的Perception B部分是错误的，因为至少有一个主要的编译器根据inline关键字更改了其优化行为。
但是，我们也可以看到inline只是一个提示，其他因素可能会超过它。

两者都是正确的。
inline的使用可能会（也可能不会）影响编译器决定内联任何特定的函数调用。所以A是正确的--它作为一个非绑定的请求，调用被内联的函数，编译器可以自由忽略。
inline的语义效果是放宽了一个定义规则的限制，允许在多个翻译单元中使用相同的定义，如B中所述。对于许多编译器来说，这是允许内联函数调用所必需的-定义必须在那一点上可用，并且编译器一次只需要处理一个翻译单元。

我只是想发布一个inline影响内联的概念验证示例。
Here it is：

namespace {
struct S {
    auto foo(unsigned int x) {
        ++x; x *= x;
        ++x; x *= x;
        ++x; x *= x;
        ++x; x *= x;
        ++x; x *= x;
        ++x; x *= x;
        ++x; x *= x;
        ++x; x *= x;
        return x;
    }
    inline auto bar(unsigned int x) {
        ++x; x *= foo(x);
        ++x; x *= foo(x);
        ++x; x *= foo(x);
        ++x; x *= foo(x);
        ++x; x *= foo(x);
        return x;
    }
    auto baz(unsigned int x) {
        ++x; x *= bar(x);
        ++x; x *= bar(x);
        ++x; x *= bar(x);
        ++x; x *= bar(x);
        return x;
    }
};
}
int main(int argc, char *argv[]) {
    return S().baz(argc);
}

即使使用-O3，Clang 16.0.0也不会内联bar;在这种情况下，您将在输出中看到call指令。但是如果您将inline添加到bar，则这些将完全内联，并且call指令将消失。* 尽管所有方法都是语义隐式内联的！*
这个例子显然是人为设计的，但我遇到过实际情况，在这种情况下，它会导致不小的性能差异。