lkml.org 
[lkml]   [2010]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 08/10] jump label v11: x86 support
From
Date
On Tue, 2010-09-21 at 17:29 +0200, Ingo Molnar wrote:

> > >From the documentation patch:
> >
> > " The optimization depends on !CC_OPTIMIZE_FOR_SIZE. When
> > CC_OPTIMIZE_FOR_SIZE is set, gcc does not always out of line the not
> > taken label path in the same way that the "if unlikely()" paths are
> > made out of line. Thus, with CC_OPTIMIZE_FOR_SIZE set, this
> > optimization is not always optimal. This may be solved in subsequent
> > gcc versions, that allow us to move labels out of line, while still
> > optimizing for size. "
>
> OTOH making a difficult optimization (HAVE_ARCH_JUMP_LABEL) dependent on
> compiler flags is really asking for trouble.
>
> So how about enabling it unconditionally, and just chalk up the cost
> under CC_OPTIMIZE_FOR_SIZE as one of the costs it already has? This also
> has the advantage that future compilers can improve things without
> having to wait for yet another kernel patch that re-enables
> HAVE_ARCH_JUMP_LABEL.

Agreed,

CC_OPTIMIZE_FOR_SIZE does not mean OPTIMIZE_FOR_PERFORMANCE. Although
people have argued that with smaller size you gain better cache
performance. I've noticed that the general case is that optimizing for
size has decreased performance (although I have not done any official
benchmarks, just my own personal observations).

I thought you may have had that there because OPTIMIZE_FOR_SIZE actually
broke the code (as some gcc compilers do for function graph tracer). If
its just a "we don't perform better with this set". Then get rid of it.

Thanks,

-- Steve




\
 
 \ /
  Last update: 2010-09-21 17:37    [W:0.104 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site