https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 15 Jul 2014, daniel.santos at pobox dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782 > > --- Comment #6 from Daniel Santos <daniel.santos at pobox dot com> --- > (In reply to Richard Biener from comment #3) > > Note that if such function is called indirectly the compiler may > > or may not inline it dependent on optimization level and a failure > > to inline an indirect call may or may not be diagnosed. > > OMG!! Thank you SO much for this clarification! I'm the crazy C > metaprogramming guy and I depend upon -findirect-inline and > always_inline to facilitate what I'm calling "C pseudo-templates." This > would explain some odd circumstances where I've seen such functions not > get inlined. I've been able to remedy this (thus far) by marking the > calling function with __attribute__((flatten)), but I have to take great > care to catch this, ensuring that that I check each value that I expect > to be constant with __builtin_constant_p and generate an error when they > aren't. Heh - I've been there as well and guess what - I invented __attribute__((flatten)) because of this... Note that flatten has the same issues as always_inline with respect to indirect function calls (or virtual method calls, which are indirect calls). > Portions of these functions (often the majority) I expect to be executed by > the > compiler and the result emitted, rather than having the whole of the function > emitted as generated code. As the complexity of such functions grows, the cost > of failing to inline by indirection can be the explosion of the function to > 10, > 20 times or more of it's size when all inlining happens. (sorry, that's a > little off topic). Yeah, similar catastrophic things happened in the past with profile-feedback where instrumentation was applied _before_ all inlining... (I changed that as well).
