Re: [PATCH 6/13: eCryptfs] Superblock operations

[Dave Kleikamp]

On Fri, 2006-05-05 at 15:03 +0100, David Howells wrote:
> Dave Kleikamp <shaggy@xxxxxxxxxxxxxx> wrote:
> 
> > > But it may use more stack, which is a much more limited resource, so what
> > > you suggest is not necessarily the best thing to do.
> > 
> > I think either way it's coded, the compiler will probably store the
> > result in a register.
> 
> There's an apparent function call between the two usages of the value.  So
> even if the value is placed in a register, that register must either be saved
> on the stack around the function call (if it's callee-clobbered), or the
> register must be saved on the stack before the value is placed in it (if it's
> callee-saved).

Probably true unless it can reuse a callee-saved register.

> Either way, it will use more stack; the mere fact that whilst it's using the
> value, the compiler may stash it in a register is irrelevant.

Is the stack usage very close to exceeding 4 KB?  Could saving one more
pointer on the stack cause a problem?  Anyway, it's not that big of a
deal.  The code may look a little cleaner with a local variable, but
it's not that bad as it is.

> > I would recommend the most readable approach (which I believe would be using
> > a local variable) and leave the optimization to the compiler.
> 
> Whilst it may be more readable, it doesn't mean it's more optimal.  You're
> just trading stack usage for code size.  The function call in the middle
> limits the optimisation the compiler can do.
> 
> Of course, if the thing in the middle is not actually a function call, or if
> it can be inlined, then this _might_ not apply.  It may even be possible that
> the compiler will discard the variable and fetch it again from memory if it
> considers the value in memory to be unchanging for the duration.

It looks like a real function call.

Shaggy
-- 
David Kleikamp
IBM Linux Technology Center

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/