https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Matthias Kretz (Vir) from comment #3) > (In reply to Jakub Jelinek from comment #2) > > I bet by adding too many always_inline functions that call normal inlines > > that is what is bound to happen, one runs into inline growth limits. It is > > better to use always_inline on the leaf functions rather than on what calls > > them. > > How is the inline growth limit determined? I mean, in the cases where it > really hurts, the resulting function compiles down to a single instruction > (plus parameter passing boilerplate). The optimizer cannot know about the > number of instructions, so what is the measure it uses? I've CCed Honza, who should know the answers. The inliner can't know if say some builtin will fold into a single instruction or not, it uses some heuristics on GIMPLE IL sizes. Bet -fdump-ipa-inline-details contain all the reasons, but at least for me those dumps are hard to read.
