lkml.org 
[lkml]   [2005]   [May]   [26]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
From<>
SubjectRe: ntfs: remove redundant assignments
DateThu, 26 May 2005 04:39:00 -0400
---- Original Message ----- 
From: "Al Viro" <viro@parcelfarce.linux.theplanet.co.uk>
To: "Pekka J Enberg" <penberg@cs.helsinki.fi>
Cc: "Anton Altaparmakov" <aia21@cam.ac.uk>;
<linux-ntfs-dev@lists.sourceforge.net>; <linux-kernel@vger.kernel.org>
Sent: Thursday, May 26, 2005 03:04
Subject: Re: ntfs: remove redundant assignments> On Thu, May 26, 2005 at 09:21:46AM +0300, Pekka J Enberg wrote:
> > On Wed, 2005-05-25 at 22:10 +0100, Anton Altaparmakov wrote:
> > >This is not.  memset(0) is not the same as = NULL IMO.  I don't care if
> > >the compiler thinks it is the same.  NULL does not have to be 0 so I
> > >prefer to initialize pointers explicitly to NULL.  Even more so since
this
> > >code is not performance critical at all so I prefer clarity here.

FWIW, a series of explicit assignments to zero puffs up the code on x86.
Several GCC releases using the default kernel -O2 build are too dumb to zero
EAX, or some other reg, and assign using it, so you're looking at 4 bytes of
immediate zero plus opcode ModRm/SIB.  If the locations being assigned
happened to be statics you can often wind up with a 10 byte instruction to
zero a single dword somewhere.

I have tried a few tricks trying to get GCC to not use this 4 byte immediate
0 in non speed critical areas all to no avail (ex. foo &= 0;  the AND
instruction can use a one byte sign extended operand, but GCC morphs
something like " &= 0" into a straight up "MOV thing,imm32" instruction)



-
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: 2005-05-26 09:51    [from the cache]
©2003-2008