> I don't buy that performance argument, in this case. You are already
> dirtying the same cacheline with other variable initializations.
>
> Like I noted in the changeset description (hey, this is precisely why
> I included it, so that we could have this discussion), IMO the flow of
> control makes it not only impossible for the compiler to understand
> the full value range of 'f0', but also difficult for humans as well.
>
> I could perhaps understand initializing the variable to some poison
> value rather than zero, but IMO the code is stronger with f0 set to a
> sane value.
The more I think about it, the less sense initializing f0 to 0 makes.
The whole problem with an uninitialized variable is that a random
value from the stack might be used. So setting a variable to
something meaningless (guaranteeing that a garbage value is used in
case of a bug) just to shut up a warning makes no sense -- it's no
safer than leaving the code as is. uninitialized_var() gets rid of
the warning, saves a little text and instruction cache, and documents
things better.
(BTW, I agree the code is a little confusing as written. I think
things could be cleaned up and made more efficient by getting rid of
the initialization of size0 too -- I'll look at doing that)
Anyway, I queued this up for my next merge with Linus:
commit 6d7d080e9f7cd535a8821efd3835c5cfa5223ab6
Author: Roland Dreier <[email protected]>
Date: Tue Jul 17 19:30:51 2007 -0700
IB/mthca: Use uninitialized_var() for f0
Commit 9db48926 ("drivers/infiniband/hw/mthca/mthca_qp: kill uninit'd
var warning") added "= 0" to the declarations of f0 to shut up gcc
warnings. However, there's no point in making the code bigger by
initializing f0 to a random value just to get rid of a warning;
setting f0 to 0 is no safer than just using uninitialized_var(), which
documents the situation better and gives smaller code too. For example,
on x86_64:
add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-16 (-16)
function old new delta
mthca_tavor_post_send 1352 1344 -8
mthca_arbel_post_send 1489 1481 -8
Signed-off-by: Roland Dreier <[email protected]>
diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c b/drivers/infiniband/hw/mthca/mthca_qp.c
index 11f1d99..0e9ef24 100644
--- a/drivers/infiniband/hw/mthca/mthca_qp.c
+++ b/drivers/infiniband/hw/mthca/mthca_qp.c
@@ -1591,7 +1591,13 @@ int mthca_tavor_post_send(struct ib_qp *ibqp, struct ib_send_wr *wr,
int i;
int size;
int size0 = 0;
- u32 f0 = 0;
+ /*
+ * f0 is only used if nreq != 0, and f0 will be initialized
+ * the first time through the main loop, since size0 == 0 the
+ * first time through. So nreq cannot become non-zero without
+ * initializing f0, and f0 is in fact never used uninitialized.
+ */
+ u32 uninitialized_var(f0);
int ind;
u8 op0 = 0;
@@ -1946,7 +1952,13 @@ int mthca_arbel_post_send(struct ib_qp *ibqp, struct ib_send_wr *wr,
int i;
int size;
int size0 = 0;
- u32 f0 = 0;
+ /*
+ * f0 is only used if nreq != 0, and f0 will be initialized
+ * the first time through the main loop, since size0 == 0 the
+ * first time through. So nreq cannot become non-zero without
+ * initializing f0, and f0 is in fact never used uninitialized.
+ */
+ u32 uninitialized_var(f0);
int ind;
u8 op0 = 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
