سؤال

أحصل على تحذير متمرس مثل:

  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.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top