Я не был уверен в вашем утверждении:

Меньшие функции автоматически "встраиваются" оптимизатором независимо от того, упоминается он или нет ... Совершенно ясно, что пользователь не имеет никакого контроля над функцией "встраивание" с использованием ключевого слова inline.

Я слышал, что компиляторы могут игнорировать ваш inline запрос, но я не думаю, что они полностью его проигнорировали.

Я просмотрел репозиторий Github, чтобы найти Clang и LLVM. (Спасибо, программное обеспечение с открытым исходным кодом!) Я обнаружил, что ключевое слово inline действительно повышает вероятность встраивания функции в Clang / LLVM.

Поиск

Поиск слова inline в репозитории Clang приводит к спецификатору токена kw_inline. Похоже, что Clang использует умную систему на основе макросов для создания лексического анализатора и других функций, связанных с ключевыми словами, так что прямых упоминаний типа if (tokenString == "inline") return kw_inline не обнаружено. Но здесь в >, мы видим, что 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 в другом месте мы видим, что это единственный бит в битовом поле и используется в функции получения, isInlineSpecified():

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

Выполняя поиск сайтов для звонков isInlineSpecified(), мы находим кодогенератор, в котором мы конвертируем дерево синтаксического анализа 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 на репозиторий LLVM.

Поиск llvm::Attribute::InlineHint / a> 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;

getInlineThreshold(), похоже, имеет только , участник SimpleInliner:

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

Выполняя поиск ::getInlineCost(), чтобы найти версии, являющиеся членами класса, мы находим одну, которая является членом AlwaysInline, что является нестандартной, но широко поддерживаемой функцией компилятора, а другую - членом InlineCostAnalysis. Он использует свой параметр Threshold / а>:

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

CallAnalyzer::analyzeCall() содержит более 200 строк, а

InlineCallIfPossible() выполняет встраивание на основе решения shouldInline().

Оба верны.

Использование inline могло или не могло повлиять на решение компилятора встроить любой конкретный вызов функции. Итак, A правильный - он действует как необязательный запрос, который вызывает встроенную функцию, которую компилятор может игнорировать.

Семантический эффект inline состоит в том, чтобы ослабить ограничения правила одного определения, чтобы разрешить идентичные определения в нескольких единицах перевода, как описано в B. Для многих компиляторов это необходимо, чтобы разрешить встраивание вызовов функций - определение должно быть доступно по адресу в этот момент, и компиляторы должны обрабатывать только одну единицу перевода за раз.