[Bug ipa/66122] Bad uninlining decisions

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Denis Vlasenko from comment #8)
> If you try to reproduce this with kernel build, be sure to not select
> CONFIG_OPTIMIZE_INLINING (it forces inlining by making all iniline functions
> __always_inline).
> 
> I didn't mention it before, but the recent (as of this writing) gcc 5.1.1
> 20150422 (Red Hat 5.1.1-1) with -Os easily triggers this behavior (more than
> a thousand *.o modules with spurious deinlines during kernel build).

If you expect that all functions with inline keyword must be always inlined,
then you really should use __always_inline__ attribute.  Otherwise, inline
keyword is primarily an optimization hint to the compiler that it might be
desirable to inline it.  So, talking about uninlining or deinlining makes
absolutely no sense, the compiler either chooses to inline a function, or
doesn't, based on some heuristics, command line options etc.
For -Os, not inlining a function declared with inline keyword is often the
right thing to do.  And as Richard said, you can always look at the dump file
to see why something hasn't been inlined.