سؤال
أحصل على تحذير متمرس مثل:
warning: inlining failed in call to ‘symbol_Arity’: call is unlikely and code size would grow
للتخلص من هذا ، قمت بتغيير جهاز Makefile لإزالة الخط للتخلص من هذا. لا أحصل على أي تحذير مضمون. لكنني لا أعرف كم هو حكيم في القيام به فيما يتعلق بالأداء. هل يمكن لأحد أن يقترحني حيال ذلك؟
أضاف المزيد من المعلومات:
هنا تحذير:
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
والرمز المقابل هو:
من القائمة
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 }
ومن البحث
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 ++. يجب ألا تحصل على تحذير مع ذلك.
لقد تعثرت هنا بعد تجميع بعض التعليمات البرمجية القديمة مع -error -winline -تحذير أريده افتراضيًا لأنه يجد أخطاء كبيرة ، حيث نسيت مشغلي المهام وما إلى ذلك.
ومع ذلك ، بالنسبة لوظيفة معينة ، فأنا بحاجة إلى أن تكون دائمًا مضطرًا ، وبالتالي كنت بحاجة إلى وسيلة لقمع تحذير لهذه الكتلة فقط من الكود.
#pragma GCC diagnostic ignored "-Winline"
كان الخيار الواضح ، لكنه في الواقع لا يقمع هذا التحذير. الحل هو استخدام السمة دائمًا:
inline bool function() __attribute__((always_inline));
inline bool function() { /*something*/ };
هذا سوف يتخلص من التحذير ويجبر دائمًا على الإدخال
لا أرى مشكلة في ذلك!
لا ينبغي أن يكون هناك تأخر في الأداء ، كما أفهم ، coz ، المعامل المترجم يعامل المضمون كدالة منتظمة!
انظر ما يقوله مجلس التعاون الخليجي!
-أين
تحذير إذا لم يكن من الممكن أن يتم إدخال وظيفة وتم إعلانها على أنها مضمنة. حتى مع هذا الخيار ، لن يحذر المترجم من الإخفاقات في الوظائف المضمنة المعلنة في رؤوس النظام. يستخدم المترجم مجموعة متنوعة من الاستدلال لتحديد ما إذا كان يجب مضمنة الوظيفة أم لا. على سبيل المثال ، يأخذ برنامج التحويل البرمجي في الاعتبار حجم الوظيفة التي يتم تضمينها ومقدار الادعاء الذي تم بالفعل في الوظيفة الحالية. لذلك ، يمكن أن تتسبب التغييرات غير المهمة على ما يبدو في برنامج المصدر في الظهور أو تختفي التحذيرات التي تنتجها -Winline.