lkml.org 
[lkml]   [2006]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Synchronizing Bit operations V2
On Thu, Mar 30, 2006 at 04:58:25PM -0800, Christoph Lameter wrote:
> On Thu, 30 Mar 2006, Luck, Tony wrote:
>
> > > Also some higher level functions may want to have the mode passed to them
> > > as parameters. See f.e. include/linux/buffer_head.h. Without the
> > > parameters you will have to maintain farms of definitions for all cases.
> >
> > But if any part of the call chain from those higher level functions
> > down to these low level functions is not inline, then the compiler
> > won't be able to collapse out the "switch (mode)" ... so we'd end up
> > with a ton of extra object code.
>
> Correct. But such bitops are typically defined to be inline.

That's doesn't seem to be the point that Tony was making. To illustrate
it let's add a practical example:

static inline void clear_bit_mode(int bit, unsigned long *ptr, int mode)
{
case (mode) {
...
}
}

void foo(blah blah, int mode)
{
... complex function ...
clear_bit_mode(bit, ptr, mode);
...
}

void bar(blah blah)
{
foo(blah, MODE_BARRIER);
}

In this case, the compiler can not optimise the unnecessary code from
the clear_bit_mode because the mode argument quite definitely is not a
constant known at compile time. Only if 'foo' was a static inline
would it be known.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-04-03 14:41    [W:0.027 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site