[PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[Denis Cheng]

From: Denis Cheng <crquan@gmail.com>

the explicit memset call could be optimized out by data initialization,
thus all the fill working can be done by the compiler implicitly.

Signed-off-by: Denis Cheng <crquan@gmail.com>

---
Is there some comments on this?

--- arch/x86_64/mm/init.c.orig	2007-06-07 10:08:04.000000000 +0800
+++ arch/x86_64/mm/init.c	2007-06-18 14:43:15.000000000 +0800
@@ -406,8 +406,7 @@ void __cpuinit zap_low_mappings(int cpu)
 #ifndef CONFIG_NUMA
 void __init paging_init(void)
 {
-	unsigned long max_zone_pfns[MAX_NR_ZONES];
-	memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
+	unsigned long max_zone_pfns[MAX_NR_ZONES] = { 0, };
 	max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN;
 	max_zone_pfns[ZONE_DMA32] = MAX_DMA32_PFN;
 	max_zone_pfns[ZONE_NORMAL] = end_pfn;

Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[Robert P. J. Day]

On Mon, 18 Jun 2007, Denis Cheng wrote:

> From: Denis Cheng <crquan@gmail.com>
>
> the explicit memset call could be optimized out by data initialization,
> thus all the fill working can be done by the compiler implicitly.
>
> Signed-off-by: Denis Cheng <crquan@gmail.com>
>
> ---
> Is there some comments on this?
>
> --- arch/x86_64/mm/init.c.orig	2007-06-07 10:08:04.000000000 +0800
> +++ arch/x86_64/mm/init.c	2007-06-18 14:43:15.000000000 +0800
> @@ -406,8 +406,7 @@ void __cpuinit zap_low_mappings(int cpu)
>  #ifndef CONFIG_NUMA
>  void __init paging_init(void)
>  {
> -	unsigned long max_zone_pfns[MAX_NR_ZONES];
> -	memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
> +	unsigned long max_zone_pfns[MAX_NR_ZONES] = { 0, };

the drawback i see to this is that it's *visually* misleading.  it
*appears* that what the programmer is trying to do is just initialize
the first element, not all of them -- regardless of the actual effect.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[WANG Cong]

On Mon, Jun 18, 2007 at 06:25:17AM -0400, Robert P. J. Day wrote:
>On Mon, 18 Jun 2007, Denis Cheng wrote:
>
>> From: Denis Cheng <crquan@gmail.com>
>>
>> the explicit memset call could be optimized out by data initialization,
>> thus all the fill working can be done by the compiler implicitly.
>>
>> Signed-off-by: Denis Cheng <crquan@gmail.com>
>>
>> ---
>> Is there some comments on this?
>>
>> --- arch/x86_64/mm/init.c.orig	2007-06-07 10:08:04.000000000 +0800
>> +++ arch/x86_64/mm/init.c	2007-06-18 14:43:15.000000000 +0800
>> @@ -406,8 +406,7 @@ void __cpuinit zap_low_mappings(int cpu)
>>  #ifndef CONFIG_NUMA
>>  void __init paging_init(void)
>>  {
>> -	unsigned long max_zone_pfns[MAX_NR_ZONES];
>> -	memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
>> +	unsigned long max_zone_pfns[MAX_NR_ZONES] = { 0, };
>
>the drawback i see to this is that it's *visually* misleading.  it
>*appears* that what the programmer is trying to do is just initialize
>the first element, not all of them -- regardless of the actual effect.
>

C standard can guarantee all of them are initialized, and this is _not_
hard to understand for a good C programmer.

Ack for Denis's change.

Regards!

Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[Jeremy Fitzhardinge]

Denis Cheng wrote:
> From: Denis Cheng <crquan@gmail.com>
>
> the explicit memset call could be optimized out by data initialization,
> thus all the fill working can be done by the compiler implicitly.
>   

How does the generated code change?  Does gcc do something stupid like
statically allocate a prototype structure full of zeros, and then memcpy
it in?  Or does it generate a series of explicit assignments for each
member?  Or does it generate a memset anyway?

Seems to me that this gives gcc the opportunity to be more stupid, and
the only right answer is what we're doing anyway.

    J

Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[Adrian Bunk]

On Mon, Jun 18, 2007 at 10:07:21AM -0700, Jeremy Fitzhardinge wrote:
> Denis Cheng wrote:
> > From: Denis Cheng <crquan@gmail.com>
> >
> > the explicit memset call could be optimized out by data initialization,
> > thus all the fill working can be done by the compiler implicitly.
> 
> How does the generated code change?  Does gcc do something stupid like
> statically allocate a prototype structure full of zeros, and then memcpy
> it in?  Or does it generate a series of explicit assignments for each
> member?  Or does it generate a memset anyway?
> 
> Seems to me that this gives gcc the opportunity to be more stupid, and
> the only right answer is what we're doing anyway.

I checked with gcc 4.2, and gcc is quite clever:

If an array is big, gcc uses memset.
If an array is small, gcc does it directly in assembler.

>     J

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[rae l]

On 6/19/07, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> Denis Cheng wrote:
> > From: Denis Cheng <crquan@gmail.com>
> >
> > the explicit memset call could be optimized out by data initialization,
> > thus all the fill working can be done by the compiler implicitly.
> >
>
> How does the generated code change?  Does gcc do something stupid like
> statically allocate a prototype structure full of zeros, and then memcpy
> it in?  Or does it generate a series of explicit assignments for each
> member?  Or does it generate a memset anyway?
>
> Seems to me that this gives gcc the opportunity to be more stupid, and
> the only right answer is what we're doing anyway.
>
>     J
>
Technically speaking, C standard guarantees the data be initialized correctly;
just from the point view of code style, let the compiler selects how
to initialize will be better, this could let the compiler has more
optimization points.

-- 
Denis Cheng
Linux Application Developer

Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[Arjan van de Ven]

On Sun, 2007-06-24 at 20:12 -0400, Benjamin LaHaise wrote:
> On Sun, Jun 24, 2007 at 05:09:16PM -0700, Arjan van de Ven wrote:
> > if you care about the last cycle, don't specify -Os but -O2.
> > simple as that... you get what you tell the compiler you want.
> 
> Certain distros are shipping kernels compiled with -Os.  And it's more 
> than just a couple of cycles.

so those distros pick space over some cycles. Who are you to then
override that choice ? ;-)

seriously, why are we even talking about overriding a choice the user
(or distro vendor as user) made here?

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[Benjamin LaHaise]

On Sun, Jun 24, 2007 at 05:09:16PM -0700, Arjan van de Ven wrote:
> if you care about the last cycle, don't specify -Os but -O2.
> simple as that... you get what you tell the compiler you want.

Certain distros are shipping kernels compiled with -Os.  And it's more 
than just a couple of cycles.

		-ben
-- 
"Time is of no importance, Mr. President, only life is important."
Don't Email: <zyntrop@kvack.org>.

Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[Arjan van de Ven]

On Sun, 2007-06-24 at 19:23 -0400, Benjamin LaHaise wrote:
> On Sun, Jun 24, 2007 at 03:15:17PM -0700, Arjan van de Ven wrote:
> > we should just alias our memset to the __builtin one, and then provide a
> > generic one from lib/ for the cases gcc needs to do a fallback.
> 
> The last time I checked, gcc generated horrible badly performing code for 
> builtin memset/memcpy() when -Os is specified.

if you care about the last cycle, don't specify -Os but -O2.
simple as that... you get what you tell the compiler you want.

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[Benjamin LaHaise]

On Sun, Jun 24, 2007 at 03:15:17PM -0700, Arjan van de Ven wrote:
> we should just alias our memset to the __builtin one, and then provide a
> generic one from lib/ for the cases gcc needs to do a fallback.

The last time I checked, gcc generated horrible badly performing code for 
builtin memset/memcpy() when -Os is specified.

		-ben
-- 
"Time is of no importance, Mr. President, only life is important."
Don't Email: <zyntrop@kvack.org>.

Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[Oleg Verych]

On Sun, Jun 24, 2007 at 08:58:10PM +0800, rae l wrote:
> On 6/23/07, Oleg Verych <olecom@flower.upol.cz> wrote:
> >Why not just show actual objdump output on code (maybe with different
> >oxygen atoms used in gcc), rather than *talking* about optimization and
> >standards, hm?
> here is the objdump output of the two object files:
> As you could see, the older one used 0x38 bytes stack space while the
> new one used 0x28 bytes,
> and the object code is two bytes less,

Actually more: $((0x3d9 - 0x3ce))

> I think all these benefits are the gcc's __builtin_memset optimization
> than the explicit call to memset.

... or from complex memset() implementation (some chips even didn't do
`rep' fast enough somehow). Maybe code like below will be acceptable for
both optimizers and maintainers?

|-*-
        unsigned long max_zone_pfns[MAX_NR_ZONES] = {
                [ZONE_DMA] = MAX_DMA_PFN,
                [ZONE_DMA32] = MAX_DMA32_PFN,
                [ZONE_NORMAL] = end_pfn,
                [ZONE_MOVABLE] = 0UL
        };
|-*-

> $ objdump -d /tmp/init.orig.o|grep -A23 -nw '<paging_init>'
[]
> 547- 3d9:       c3                      retq
[]
> 545- 3ce:       c3                      retq
[]
> >
> >I bet, that will be a key for success. And if you are interested in such
> >optimizations, why not to grep whole source tree for this kind of
> >things? I'm not sure one function in arch/x86_64 is only such 
> >``unoptimized''.
> >And after doing that maybe you will see, that "{}" initializer can be
> >applied not only to integer values (you did init with of *long int*,
> >with *int*, btw), but to structs and others.
> with '{}' initializer, gcc will fill its memory with zeros.
> 
> to other potential points to be optimized, I only see this trivial as
> the first point, I wonder how people gives comments on this; and if
> this optimization can be tested correctly, this can be done as an
> optimization example and I'll try others.

Yes, comments and discussion is most important thing. But with such
propositions you will be better in the kernel-janitors list.

> >
> >Ahh, one more thing about _optimizing_ your time, i.e. not wasting one.
> >
> >Add to CC list people, who already did reply on you patch. Otherwise
> >you are showing your disrespect for them and hiding from further
> >discussion.
> Thank you, I know it and I've already subscribed the linux kernel
> mailing list(linux-kernel@vger.kernel.org) so that I won't miss any
> further discussion about it.

OK, but news<=>e-mail service, like Gmane is much nicer.

> >
> >I think you do not, but Linux development not have an automatic system
> >for patch tracking, so you are on your own with your text editor and
> >e-mail client on this. Please take care for your time.
> What about that?
> Do you mean something such as git by "an automatic system"?

That was a side note.
____

Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[Arjan van de Ven]

> > I think all these benefits are the gcc's __builtin_memset optimization
> > than the explicit call to memset.
> 
> ... or from complex memset() implementation (some chips even didn't do
> `rep' fast enough somehow). Maybe code like below will be acceptable for
> both optimizers and maintainers?


we should just alias our memset to the __builtin one, and then provide a
generic one from lib/ for the cases gcc needs to do a fallback.

Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[rae l]

On 6/23/07, Oleg Verych <olecom@flower.upol.cz> wrote:
> Why not just show actual objdump output on code (maybe with different
> oxygen atoms used in gcc), rather than *talking* about optimization and
> standards, hm?
here is the objdump output of the two object files:
As you could see, the older one used 0x38 bytes stack space while the
new one used 0x28 bytes,
and the object code is two bytes less,
I think all these benefits are the gcc's __builtin_memset optimization
than the explicit call to memset.

$ objdump -d /tmp/init.orig.o|grep -A23 -nw '<paging_init>'
525:0000000000000395 <paging_init>:
526- 395:       48 83 ec 38             sub    $0x38,%rsp
527- 399:       48 8d 54 24 10          lea    0x10(%rsp),%rdx
528- 39e:       fc                      cld
529- 39f:       31 c0                   xor    %eax,%eax
530- 3a1:       48 89 d7                mov    %rdx,%rdi
531- 3a4:       ab                      stos   %eax,%es:(%rdi)
532- 3a5:       ab                      stos   %eax,%es:(%rdi)
533- 3a6:       ab                      stos   %eax,%es:(%rdi)
534- 3a7:       ab                      stos   %eax,%es:(%rdi)
535- 3a8:       ab                      stos   %eax,%es:(%rdi)
536- 3a9:       48 89 7c 24 08          mov    %rdi,0x8(%rsp)
537- 3ae:       ab                      stos   %eax,%es:(%rdi)
538- 3af:       48 c7 44 24 10 00 10    movq   $0x1000,0x10(%rsp)
539- 3b6:       00 00
540- 3b8:       48 c7 44 24 18 00 00    movq   $0x100000,0x18(%rsp)
541- 3bf:       10 00
542- 3c1:       48 8b 05 00 00 00 00    mov    0(%rip),%rax        #
3c8 <paging_init+0x33>
543- 3c8:       48 89 44 24 20          mov    %rax,0x20(%rsp)
544- 3cd:       48 89 d7                mov    %rdx,%rdi
545- 3d0:       e8 00 00 00 00          callq  3d5 <paging_init+0x40>
546- 3d5:       48 83 c4 38             add    $0x38,%rsp
547- 3d9:       c3                      retq
548-
$ objdump -d /tmp/init.new.o|grep -A23 -nw '<paging_init>'
525:0000000000000395 <paging_init>:
526- 395:       48 83 ec 28             sub    $0x28,%rsp
527- 399:       48 89 e7                mov    %rsp,%rdi
528- 39c:       fc                      cld
529- 39d:       31 c0                   xor    %eax,%eax
530- 39f:       ab                      stos   %eax,%es:(%rdi)
531- 3a0:       ab                      stos   %eax,%es:(%rdi)
532- 3a1:       ab                      stos   %eax,%es:(%rdi)
533- 3a2:       ab                      stos   %eax,%es:(%rdi)
534- 3a3:       ab                      stos   %eax,%es:(%rdi)
535- 3a4:       ab                      stos   %eax,%es:(%rdi)
536- 3a5:       48 c7 04 24 00 10 00    movq   $0x1000,(%rsp)
537- 3ac:       00
538- 3ad:       48 c7 44 24 08 00 00    movq   $0x100000,0x8(%rsp)
539- 3b4:       10 00
540- 3b6:       48 8b 05 00 00 00 00    mov    0(%rip),%rax        #
3bd <paging_init+0x28>
541- 3bd:       48 89 44 24 10          mov    %rax,0x10(%rsp)
542- 3c2:       48 89 e7                mov    %rsp,%rdi
543- 3c5:       e8 00 00 00 00          callq  3ca <paging_init+0x35>
544- 3ca:       48 83 c4 28             add    $0x28,%rsp
545- 3ce:       c3                      retq
546-
547-00000000000003cf <alloc_low_page>:
548- 3cf:       41 56                   push   %r14


>
> I bet, that will be a key for success. And if you are interested in such
> optimizations, why not to grep whole source tree for this kind of
> things? I'm not sure one function in arch/x86_64 is only such ``unoptimized''.
> And after doing that maybe you will see, that "{}" initializer can be
> applied not only to integer values (you did init with of *long int*,
> with *int*, btw), but to structs and others.
with '{}' initializer, gcc will fill its memory with zeros.

to other potential points to be optimized, I only see this trivial as
the first point, I wonder how people gives comments on this; and if
this optimization can be tested correctly, this can be done as an
optimization example and I'll try others.

>
> Ahh, one more thing about _optimizing_ your time, i.e. not wasting one.
>
> Add to CC list people, who already did reply on you patch. Otherwise
> you are showing your disrespect for them and hiding from further
> discussion.
Thank you, I know it and I've already subscribed the linux kernel
mailing list(linux-kernel@vger.kernel.org) so that I won't miss any
further discussion about it.

>
> I think you do not, but Linux development not have an automatic system
> for patch tracking, so you are on your own with your text editor and
> e-mail client on this. Please take care for your time.
What about that?
Do you mean something such as git by "an automatic system"?

>
> --
>   frenzy
> -o--=O`C
>  #oo'L O
> <___=E M
>


-- 
Denis Cheng
Linux Application Developer

Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[Segher Boessenkool]

> gcc is a C compiler and claims to follow the C standard.

Not with the options the kernel build uses.  But, close
enough -- the differences are really minor stuff.


Segher

Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[Adrian Bunk]

On Sat, Jun 23, 2007 at 03:41:26PM +0200, Oleg Verych wrote:
> On Sat, Jun 23, 2007 at 03:13:55PM +0200, Adrian Bunk wrote:
> > On Sat, Jun 23, 2007 at 09:59:33AM +0200, Oleg Verych wrote:
> []
> > > > From: Denis Cheng <crquan@gmail.com>
> > > >
> > > > the explicit memset call could be optimized out by data initialization,
> > > > thus all the fill working can be done by the compiler implicitly.
> > > 
> > > Can be optimized and can be done by compiler are just words;
> > > 
> > > > and C standard guaranteed all the unspecified data field initialized to zero.
> > > 
> > > standards and implementation are on opposite poles of magnet
> > 
> > Bullshit.
> > 
> > We expect a C compiler, and if a C compiler violates the C standard 
> > that's a bug in the compiler that has to be fixed.
> 
> If you are serious, please consider last kernel headers vs ANSI C
> discussion,

If only Joerg would tell us where the problem exactly is...

There might be a bug in the kernel header, but this simply has to be 
fixed.

> then GNU extensions of the GCC C compiler and relevant "if
> ICC doesn't support GCC extensions it's ICC's bug".

gcc is a C compiler and claims to follow the C standard.
The kernel does not claim to be compilable by a plain C compiler.

Spot the difference?

> That was about
> implementation. About standards you are not serious, aren't you?
> (Please don't see this as for this particular case, but as general
> viewpoint)

And as with many generalizations, that's often wrong...

> > And gcc is usually quite good in following the C standard.
> 
> > > > Signed-off-by: Denis Cheng <crquan@gmail.com>
> > > >
> > > > ---
> > > > After comments in the former threads:
> > > > http://lkml.org/lkml/2007/6/18/119
> > > 
> > > i see a patch
> > > 
> > > > http://lkml.org/lkml/2007/6/18/48
> > > 
> > > same patch.
> > >...
> > 
> > Open your eyes and you'll find thread overviews at the left side of 
> > the URLs he gave...
> 
> Two threads with *different* URLs but with *same* patch...
>...

The comments are in the _threads_.
The patches are only the roots of the threads.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[Oleg Verych]

On Sat, Jun 23, 2007 at 03:13:55PM +0200, Adrian Bunk wrote:
> On Sat, Jun 23, 2007 at 09:59:33AM +0200, Oleg Verych wrote:
[]
> > > From: Denis Cheng <crquan@gmail.com>
> > >
> > > the explicit memset call could be optimized out by data initialization,
> > > thus all the fill working can be done by the compiler implicitly.
> > 
> > Can be optimized and can be done by compiler are just words;
> > 
> > > and C standard guaranteed all the unspecified data field initialized to zero.
> > 
> > standards and implementation are on opposite poles of magnet
> 
> Bullshit.
> 
> We expect a C compiler, and if a C compiler violates the C standard 
> that's a bug in the compiler that has to be fixed.

If you are serious, please consider last kernel headers vs ANSI C
discussion, then GNU extensions of the GCC C compiler and relevant "if
ICC doesn't support GCC extensions it's ICC's bug". That was about
implementation. About standards you are not serious, aren't you?
(Please don't see this as for this particular case, but as general
viewpoint)

> And gcc is usually quite good in following the C standard.

> > > Signed-off-by: Denis Cheng <crquan@gmail.com>
> > >
> > > ---
> > > After comments in the former threads:
> > > http://lkml.org/lkml/2007/6/18/119
> > 
> > i see a patch
> > 
> > > http://lkml.org/lkml/2007/6/18/48
> > 
> > same patch.
> >...
> 
> Open your eyes and you'll find thread overviews at the left side of 
> the URLs he gave...

Two threads with *different* URLs but with *same* patch...
> 
> cu
> Adrian

Where's constructive context and support of yet another patch author,
Adrian?

> -- 
> 
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed
> 
____

Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[Adrian Bunk]

On Sat, Jun 23, 2007 at 09:59:33AM +0200, Oleg Verych wrote:
> * From: Denis Cheng
> * Newsgroups: linux.kernel
> * Date: Fri, 22 Jun 2007 22:15:49 -0700 (PDT)
>  
> > From: Denis Cheng <crquan@gmail.com>
> >
> > the explicit memset call could be optimized out by data initialization,
> > thus all the fill working can be done by the compiler implicitly.
> 
> Can be optimized and can be done by compiler are just words;
> 
> > and C standard guaranteed all the unspecified data field initialized to zero.
> 
> standards and implementation are on opposite poles of magnet

Bullshit.

We expect a C compiler, and if a C compiler violates the C standard 
that's a bug in the compiler that has to be fixed.

And gcc is usually quite good in following the C standard.

> > Signed-off-by: Denis Cheng <crquan@gmail.com>
> >
> > ---
> > After comments in the former threads:
> > http://lkml.org/lkml/2007/6/18/119
> 
> i see a patch
> 
> > http://lkml.org/lkml/2007/6/18/48
> 
> same patch.
>...

Open your eyes and you'll find thread overviews at the left side of 
the URLs he gave...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[Oleg Verych]

* From: Denis Cheng
* Newsgroups: linux.kernel
* Date: Fri, 22 Jun 2007 22:15:49 -0700 (PDT)
 
> From: Denis Cheng <crquan@gmail.com>
>
> the explicit memset call could be optimized out by data initialization,
> thus all the fill working can be done by the compiler implicitly.

Can be optimized and can be done by compiler are just words;

> and C standard guaranteed all the unspecified data field initialized to zero.

standards and implementation are on opposite poles of magnet

> Signed-off-by: Denis Cheng <crquan@gmail.com>
>
> ---
> After comments in the former threads:
> http://lkml.org/lkml/2007/6/18/119

i see a patch

> http://lkml.org/lkml/2007/6/18/48

same patch.

> @@ -406,8 +406,8 @@ void __cpuinit zap_low_mappings(int cpu)
>  #ifndef CONFIG_NUMA
>  void __init paging_init(void)
>  {
> -	unsigned long max_zone_pfns[MAX_NR_ZONES];
> -	memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
> +	unsigned long max_zone_pfns[MAX_NR_ZONES] = {};
> +
>  	max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN;
>  	max_zone_pfns[ZONE_DMA32] = MAX_DMA32_PFN;
>  	max_zone_pfns[ZONE_NORMAL] = end_pfn;

Why not just show actual objdump output on code (maybe with different
oxygen atoms used in gcc), rather than *talking* about optimization and
standards, hm?

I bet, that will be a key for success. And if you are interested in such
optimizations, why not to grep whole source tree for this kind of
things? I'm not sure one function in arch/x86_64 is only such ``unoptimized''.
And after doing that maybe you will see, that "{}" initializer can be
applied not only to integer values (you did init with of *long int*,
with *int*, btw), but to structs and others.

Ahh, one more thing about _optimizing_ your time, i.e. not wasting one.

Add to CC list people, who already did reply on you patch. Otherwise
you are showing your disrespect for them and hiding from further
discussion.

I think you do not, but Linux development not have an automatic system
for patch tracking, so you are on your own with your text editor and
e-mail client on this. Please take care for your time.

--
  frenzy
-o--=O`C
 #oo'L O
<___=E M

[PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization

[Denis Cheng]

From: Denis Cheng <crquan@gmail.com>

the explicit memset call could be optimized out by data initialization,
thus all the fill working can be done by the compiler implicitly.

and C standard guaranteed all the unspecified data field initialized to zero.

Signed-off-by: Denis Cheng <crquan@gmail.com>

---
After comments in the former threads:
http://lkml.org/lkml/2007/6/18/119
http://lkml.org/lkml/2007/6/18/48

On 6/18/07, Jan Engelhardt <jengelh@computergmbh.de> wrote:
> The cost is the same. "= {0}" is transformed into a bunch of movs,
> or a rep mov, (At least for x86), so is equivalent to memset (which
> will get transformed to __builtin_memset anyway). So I wonder
> what this really buys.
> 
> And, you do not even need the zero. Just write
>         ...[MAX_NR_ZONES] = {};

>         Jan
I also think this style of zero initialization would be better.
so the patch is little different:

--- arch/x86_64/mm/init.c.orig	2007-06-07 10:08:04.000000000 +0800
+++ arch/x86_64/mm/init.c	2007-06-23 13:12:26.000000000 +0800
@@ -406,8 +406,8 @@ void __cpuinit zap_low_mappings(int cpu)
 #ifndef CONFIG_NUMA
 void __init paging_init(void)
 {
-	unsigned long max_zone_pfns[MAX_NR_ZONES];
-	memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
+	unsigned long max_zone_pfns[MAX_NR_ZONES] = {};
+
 	max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN;
 	max_zone_pfns[ZONE_DMA32] = MAX_DMA32_PFN;
 	max_zone_pfns[ZONE_NORMAL] = end_pfn;