抑制内联警告
我收到 inling 警告，例如：
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 }
I am getting inling warning such as :
warning: inlining failed in call to ‘symbol_Arity’: call is unlikely and code size would grow
To get rid of this i changed the makefile removing the -Winline to get rid of this. I don't get any inlining warning. But , i don't know how wise is it to do in respect of performance. Can anybody please suggest me about it?
Added some more information:
here is th warning:
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
and the corresponding code is:
from 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 }
and from 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 }
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
唯一的“问题”是你试图强迫编译器做一些低效的事情。
使用
ìnline而不是__inline__，并尊重编译器关于什么应该内联、什么不应该内联的决定。不要试图强迫它，除非您已经分析了代码，发现它是瓶颈，并且验证了内联实际上会加速而不是减慢代码。这基本上就是警告的意思：“你要求我做一些愚蠢的事情，这会减慢代码的速度。我会忽略它”。
当然，您可以忽略（或沉默）警告，但最好的解决方案是首先不要强迫它做任何愚蠢的事情。不要使用特定于编译器的
__inline__，如果需要，请使用inline，并信任编译器来决定内联什么。The only "problem" is that you're trying to force the compiler to do something inefficient.
Use
ìnlinerather than__inline__, and respect the compilers decisions on what should or should not be inlined. Don't try to force it, unless you've already profiled the code, found it to be a bottleneck, and verified that inlining would actually speed up, rather than slow down, the code.That's essentially what the warning is saying: "you're asking me to do something stupid that'd slow down the code. I'm going to ignore it".
And sure, you can ignore (or silence) the warning, but the best solution is just to not force it to do anything stupid in the first place. Don't use the compiler-specific
__inline__, and useinlineif you need it, and trust the compiler to decide what to inline.从头文件中的函数中删除
static __inline__并将其替换为inline- C++ 标准关键字。你不应该收到这样的警告。Remove
static __inline__from the function in the header file and replace it withinline- the C++ standard keyword. You shouldn't get a warning with that.我在使用 -Werror -Winline 编译一些旧代码后偶然发现了这个警告，我默认情况下希望打开它，因为它发现重大错误，您忘记了赋值运算符等。
但是，对于特定函数，我绝对需要它始终内联，因此我需要一种方法来抑制仅针对此代码块的警告。
这是显而易见的选择，但它实际上并没有抑制这个警告。解决方案是使用属性always_inline：
这将消除警告并且实际上总是强制内联
I stumbled here after compiling some old code with -Werror -Winline - a warning that i want on by default because it finds significant errors, where you have forgotten assignment operators etc.
However, for a particular function i absolutely do need it to be always inlined, and hence i needed a way to suppress a warning for just this block of code.
Was the obvious choice, but it actually does not suppress this warning. Solution is to use attribute always_inline:
This will get rid of the warning and actually always force inlining
我不认为这有什么问题！
据我了解，不应该存在性能滞后，因为编译器将内联视为常规函数！
看看GCC怎么说！
-Winline
如果函数无法内联且已声明为内联，则发出警告。即使使用此选项，编译器也不会警告系统头文件中声明的内联函数失败。
编译器使用各种启发式方法来确定是否内联函数。例如，编译器会考虑内联函数的大小以及当前函数中已完成的内联量。因此，源程序中看似微不足道的更改可能会导致 -Winline 产生的警告出现或消失。
I don't see a problem with that!
There shouldn't be a performance lag, as I understand, coz, the compiler treats the inline as a regular function!
See what GCC has to say!
-Winline
Warn if a function can not be inlined and it was declared as inline. Even with this option, the compiler will not warn about failures to inline functions declared in system headers.
The compiler uses a variety of heuristics to determine whether or not to inline a function. For example, the compiler takes into account the size of the function being inlined and the amount of inlining that has already been done in the current function. Therefore, seemingly insignificant changes in the source program can cause the warnings produced by -Winline to appear or disappear.