https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 14 Apr 2023, chip.kerchner at ibm dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491 > > --- Comment #14 from Chip Kerchner <chip.kerchner at ibm dot com> --- > Just one more question and then I'll switch to the new bug. > > Would it help any if the functions that are "always_inline" be changed from > non-static to static? > > Eigen's approach (where this code originally came from - yes, it could be > definite be better) is to use non-static inlined function. I don't think so, you'd have to try. The compile-time issues usually show up when you have a multi-level call chain all being always-inline as we then repeatedly early-optimize the same code over and over. Usually we do that so functions become smaller for the inline heuristics but for always-inlines that wouldn't matter (but of course making the body smaller if there's more than one caller can still pay off). It really depends on the actual callgraph and code which is also why it is hard to improve. Another probably more common with C++ code issue would be that we inline into not optimized callers which means calls that are almost trivially unreachable have not been eliminated yet but get inlined. Usual heuristics would only inline small functions at this level and defer inlining of larger functions to IPA time at which point the calls might be eliminated already. Likewise calls attributed const or pure might be subject to CSE but always-inline forces them to be inlined before CSE. So what you could try is instead of always_inline use __attribute__((flatten)) on the functions containing the loop kernels for example and then disable early inlining (otherwise flatten is applied there as well) with -fno-early-inlining.
