2

我收到警告，例如：

  warning: inlining failed in call to ‘symbol_Arity’: call is unlikely and code size would grow

为了摆脱这个我改变了makefile删除-Winline来摆脱这个。我没有收到任何内联警告。但是，我不知道在性能方面这样做有多明智。有人可以建议我吗？

添加了更多信息：

这是警告：

search.c: In function ‘prfs_InsertInSortTheories’:
list.h:254: warning: inlining failed in call to ‘list_Delete’: call is unlikely and code size would grow
search.c:187: warning: called from here
list.h:254: warning: inlining failed in call to ‘list_Delete’: call is unlikely and code size would grow
search.c:189: warning: called from here

对应的代码是：

来自 list.h

254 static __inline__ void list_Delete(LIST L)
255 {
256   LIST Current;
257 
258   Current = L;
259   while (!list_Empty(Current)) {
260     L = list_Cdr(L);
261     list_Free(Current);
262     Current = L;
263   }

并来自 search.c

 176     LIST    approx;
 177     l = clause_Length(Clause);
 178     for (i = clause_FirstSuccedentLitIndex(Clause); i < l; i++) {
 179       lit = clause_GetLiteral(Clause,i);
 180       if (clause_LiteralIsMaximal(lit) &&
 181           symbol_IsBaseSort(term_TopSymbol(clause_LiteralSignedAtom(lit)))) {
 182         if (prfs_DynamicSortTheory(Search) != (SORTTHEORY)NULL
 183             && clause_NumOfSuccLits(Clause) == 1 &&
 184             clause_NumOfAnteLits(Clause) == 0)
 185           {
 186           copy = clause_Copy(Clause);
 187           list_Delete(clause_ParentClauses(copy));
 188           clause_SetParentClauses(copy,list_Nil());
 189           list_Delete(clause_ParentLiterals(copy));
 190           clause_SetParentLiterals(copy,list_Nil());
 191           clause_SetNumber(copy,clause_Number(Clause));
 192           sort_TheoryInsertClause(prfs_DynamicSortTheory(Search),Clause,
 193                                   copy,clause_GetLiteral(copy,i));
 194         }
4

4 回答 4

6

唯一的“问题”是你试图强迫编译器做一些低效的事情。

使用ìnline而不是__inline__，并尊重编译器关于应该内联或不应该内联的决定。不要试图强迫它，除非你已经分析了代码，发现它是一个瓶颈，并验证内联实际上会加速而不是减慢代码。

这基本上就是警告的意思：“你要我做一些愚蠢的事情，这会减慢代码的速度。我会忽略它”。

当然，您可以忽略（或静音）警告，但最好的解决方案是不要强迫它首先做任何愚蠢的事情。不要使用特定于编译器的__inline__，并inline在需要时使用它，并相信编译器决定内联的内容。

于 2010-05-09T19:13:35.427 回答
2

从头文件中的函数中删除static __inline__并将其替换为inline- C++ 标准关键字。你不应该收到警告。

于 2010-05-09T18:40:13.637 回答
2

在使用 -Werror -Winline 编译一些旧代码后，我偶然发现了这里——这是我默认情况下想要的警告，因为它会发现重大错误，您忘记了赋值运算符等。

然而，对于一个特定的函数，我绝对需要它总是被内联，因此我需要一种方法来抑制这个代码块的警告。

#pragma GCC diagnostic ignored "-Winline"

是显而易见的选择，但它实际上并没有抑制这个警告。解决方案是使用属性 always_inline：

inline bool function() __attribute__((always_inline));
inline bool function() { /*something*/ };

这将摆脱警告，实际上总是强制内联

于 2015-12-30T20:20:07.327 回答
1

我看不出有什么问题！

据我了解，不应该有性能滞后，因为编译器将内联视为常规函数！

看看 GCC 怎么说！

-Winline
如果函数不能被内联并且它被声明为内联，则发出警告。即使使用此选项，编译器也不会警告系统头文件中声明的内联函数失败。编译器使用各种启发式方法来确定是否内联函数。例如，编译器会考虑被内联的函数的大小以及在当前函数中已经完成的内联量。因此，源程序中看似微不足道的变化，都会导致-Winline产生的警告出现或消失。

于 2010-05-09T18:13:22.667 回答