This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/54965] [4.6 Regression] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965

--- Comment #5 from Siarhei Siamashka <siarhei.siamashka at gmail dot com> 2012-10-19 00:17:13 UTC ---
(In reply to comment #4)
> In the above case you probably want big_function_a to have all
> calls inlined.  You can then conveniently use the flatten attribute:
> 
> void __attribute__((flatten)) big_function_b (...)
> {
>   big_function_template(..., per_pixel_operation_b);
> }
> 
> GCC will then inline all calls in that function but not ICE
> when it fails to inline one case for some weird reason.

That's nice, but "flatten" attribute does not seem to be widely supported by
the compilers. For example, clang-3.1 does not support it yet and the
enhancement request is still open since 2010 -
http://llvm.org/bugs/show_bug.cgi?id=7559

As far as I know, a few different compilers are currently in real use for
building pixman for various systems: GCC, Clang, Solaris Studio and MSVC. All
of them have some sort of "always_inline" attribute support, which makes it
more universal than "flatten".

> Don't use always-inline or don't use indirect function calls to
> always-inline functions.  It makes always-inline function calls
> survive until IPA inlining where we seem to honor limits even
> though we say we should disregard them.

Is it too intrusive to fix GCC so that it would disregard limits in this case?
Or maybe introduce one more attribute which would be a strong inlining hint,
but still not cause compilation failure if some function can't be really
inlined?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]