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).

Reply via email to