質問
次のような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によって生成された警告が表示または消滅する可能性があります。