質問

次のような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         }
役に立ちましたか?

解決

唯一の「問題」は、コンパイラに非効率的なことを強制しようとしていることです。

使用する ìnline それよりも __inline__, 、そして、インラインドすべきではないものについてのコンパイラの決定を尊重します。あなたがすでにコードをプロファイルしていない限り、それを強制しようとしないでください、それがボトルネックであることがわかりました、 コードをスローダウンするのではなく、実際にスピードアップすることを確認しました。

それは本質的に警告が言っていることです:「あなたは私にコードを遅くする愚かなことをするように頼んでいます。私はそれを無視するつもりです」。

確かに、警告を無視(または沈黙させる)ことができますが、最善の解決策は、そもそも愚かなことを強制しないことです。コンパイラ固有のものを使用しないでください __inline__, 、使用してください inline 必要な場合は、コンパイラを信頼して、インラインを決定するものを決定します。

他のヒント

削除する static __inline__ ヘッダーファイルの関数から、 inline -C ++標準キーワード。それで警告を受けてはいけません。

-werror -winlineを使用して古いコードをコンパイルした後、ここで偶然見つけました。これは、課題オペレーターなどを忘れた場合に、重要なエラーが見つかったため、デフォルトで必要な警告です。

ただし、特定の機能のためには、常にインラキングする必要があるため、このコードブロックのみの警告を抑制する方法が必要でした。

#pragma GCC diagnostic ignored "-Winline"

明らかな選択でしたが、実際にはこの警告を抑制しません。解決策は、属性を使用することです。

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

これは警告を取り除き、実際には常にインラインを強制します

問題はありません!

私が理解しているように、パフォーマンスの遅れはありません、Coz、コンパイラはインラインを通常の関数として扱います!

GCCが言わなければならないことを見てください!

- ウィンライン
関数をインライン化できず、インラインとして宣言された場合に警告します。このオプションがあっても、コンパイラはシステムヘッダーで宣言されたインライン関数への障害について警告しません。コンパイラは、さまざまなヒューリスティックを使用して、関数をインラインにするかどうかを判断します。たとえば、コンパイラは、インラインされている関数のサイズと、現在の関数ですでに行われているインラインの量を考慮しています。したがって、ソースプログラムの一見取るに足らない変更により、-winlineによって生成された警告が表示または消滅する可能性があります。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top