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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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).

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.

> 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.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux