Front page | perl.perl5.porters |
Postings from March 2020
Now that we have the ability to force a function (at least on some compilers) to be inlined even if it doesn't think it would be better to do so, I came up with a list of functions that on my g++ Linux box show up as not being inlined at least sometimes. These are the functions that are potential candidates for us to say they should always be inlined. Looking at the list, I discovered several that were mistakenly inlined, which I will fix. Here are the remainder, with my recommendations. Comments welcome. I think we should trust the compiler for the following short functions. Most calls are inlined, but there are instances where they aren't for the stated reason. We already discussed SvTRUE in this regard. inlining failed in call to ‘Perl_SvTRUE’: call is unlikely and code size would grow [-Winline] inlining failed in call to ‘Perl_CvDEPTH’: call is unlikely and code size would grow [-Winline] inlining failed in call to ‘Perl_utf8_hop_back.constprop’: call is unlikely and code size would grow [-Winline] inlining failed in call to ‘Perl_utf8_to_uvchr_buf_helper.constprop’: call is unlikely and code size would grow [-Winline] I think we should change to not even request inlining the following, as they are big functions. inlining failed in call to ‘sbox32_hash_with_state.constprop’: --param max-inline-insns-single limit reached [-Winline] inlining failed in call to ‘S_gv_fetchmeth_internal’: --param max-inline-insns-single limit reached [-Winline] inlining failed in call to ‘stadtx_hash_with_state’: --param max-inline-insns-single limit reached [-Winline] inlining failed in call to ‘S_perl_hash_with_seed’: --param large-stack-frame-growth limit reached [-Winline] We can't do anything about this one: inlining failed in call to ‘S_fold_constants_eval’: function not inlinable [-Winline]Thread Next