lkml.org 
[lkml]   [2015]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC] x86: enforce inlining for atomics

* Hagen Paul Pfeifer <hagen@jauu.net> wrote:

> On 20 April 2015 at 23:56, Borislav Petkov <bp@alien8.de> wrote:
>
> > Hmm, that must be config-specific as doing
> >
> > objdump -D vmlinux | grep -i "atomic_add"
> >
> > here gives me only "drm_atomic_add_affected_connectors" matches.
> >
> > It probably gets inlined here always...
>
> Probably, the config is allyesconfig minus trace/kernel adress
> sanitizer and gcov related options.

So the thing is that allyesconfig turns on -Os:

CONFIG_CC_OPTIMIZE_FOR_SIZE=y

which is known to make bad decisions in other areas as well ...

If -Os does such bad inlining decisions (and the inlining examples you
cited are horrible!) then I guess a lot of the other 'inline'
functions are handled by it badly as well.

I'm not sure we should start fighting the compiler: if a compiler does
not take 'inline' seriously then the solution is to use another
compiler, or at least to use different compiler flags.

If inlining decisions are bad even with saner compiler options then we
can use __always_inline, and we actually do that for locking
primitives and some other low level primitives: which are typically
larger than atomics, so even reasonable compilers might uninline them.

But I'm not against your patch either. Linus, what's your preference?

Thanks,

Ingo


\
 
 \ /
  Last update: 2015-04-21 10:21    [W:0.080 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site