http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> 2012-10-19
08:36:06 UTC ---
(In reply to comment #5)
> (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?
I think the particular case is a bug in GCC, I was just mentioning that
using indirect function calls to always-inline functions is always prone
to this kind of error.
