[Bug ipa/66122] Bad uninlining decisions

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |trippels at gcc dot gnu.org

--- Comment #11 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Denis Vlasenko from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > 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,
> 
> Jakub, are you saying that compiling
> 
> static inline oid spin_unlock(spinlock_t *lock)
> {
>  __raw_spin_unlock(&lock->rlock);
> }
> 
> , where __raw_spin_unlock is a function (not macro), to a deinlined function
> 
> spin_unlock:
>         call __raw_spin_unlock
>         ret
> 
> 
> and then callers doing
> 
>          call spin_unlock
> 
> *can ever* make sense? That's ridiculous.
> 
> 
> How about this?
> 
> static inline void atomic_inc(atomic_t *v)
> {
>         asm volatile(LOCK_PREFIX "incl %0"
>                      : "+m" (v->counter));
> }
> 
> You think it's okay to not inline one insn?
> 
> 
> Kernel people did not take my patch which tries to fix this by
> __always_inining locking ops. 

That is their problem then. Every other sane project uses __always_inline for
this issue.

> Basically, they think that compiler should not do stupid things.

The compiler isn't psychic, e.g. it doesn't parse asm statements at all (so
it cannot know how many insn it contains).