Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
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 - 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/
Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
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: <[EMAIL PROTECTED]>. - 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/
Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
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 - 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/
Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
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: <[EMAIL PROTECTED]>. - 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/
memset() with zeroes (Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization)
On Sun, Jun 24, 2007 at 03:15:17PM -0700, Arjan van de Ven wrote: > > > > 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. In x86_64 there's infrastructure to check and select right memset(). Therefor it's need, i think. But if one will took a look at usage, zero memset() optimization becomes obvious, one argument off -- one reg is free from clobbering. |-*- flower-:22-rc4-mm2/arch/x86_64$ grep memset -R . | grep "[ 0,]0," | wc -l 42 flower-:22-rc4-mm2/arch/x86_64$ flower-:22-rc4-mm2/arch/x86_64$ cd .. flower-:22-rc4-mm2/arch$ grep memset -R . | grep "[ 0,]0," | wc -l 735 flower-:22-rc4-mm2/arch$ flower-:22-rc4-mm2$ grep memset -R . | grep "[ 0,]0," | wc -l 6679 flower-:22-rc4-mm2$ |-*- - 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/
Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
> > 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. - 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/
Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
On Sun, Jun 24, 2007 at 08:58:10PM +0800, rae l wrote:
> On 6/23/07, Oleg Verych <[EMAIL PROTECTED]> 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 ''
[]
> 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.
-
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/
Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
On 6/23/07, Oleg Verych <[EMAIL PROTECTED]> 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 ''
525:0395 :
526- 395: 48 83 ec 38 sub$0x38,%rsp
527- 399: 48 8d 54 24 10 lea0x10(%rsp),%rdx
528- 39e: fc cld
529- 39f: 31 c0 xor%eax,%eax
530- 3a1: 48 89 d7mov%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 10movq $0x1000,0x10(%rsp)
539- 3b6: 00 00
540- 3b8: 48 c7 44 24 18 00 00movq $0x10,0x18(%rsp)
541- 3bf: 10 00
542- 3c1: 48 8b 05 00 00 00 00mov0(%rip),%rax#
3c8
543- 3c8: 48 89 44 24 20 mov%rax,0x20(%rsp)
544- 3cd: 48 89 d7mov%rdx,%rdi
545- 3d0: e8 00 00 00 00 callq 3d5
546- 3d5: 48 83 c4 38 add$0x38,%rsp
547- 3d9: c3 retq
548-
$ objdump -d /tmp/init.new.o|grep -A23 -nw ''
525:0395 :
526- 395: 48 83 ec 28 sub$0x28,%rsp
527- 399: 48 89 e7mov%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 00movq $0x1000,(%rsp)
537- 3ac: 00
538- 3ad: 48 c7 44 24 08 00 00movq $0x10,0x8(%rsp)
539- 3b4: 10 00
540- 3b6: 48 8b 05 00 00 00 00mov0(%rip),%rax#
3bd
541- 3bd: 48 89 44 24 10 mov%rax,0x10(%rsp)
542- 3c2: 48 89 e7mov%rsp,%rdi
543- 3c5: e8 00 00 00 00 callq 3ca
544- 3ca: 48 83 c4 28 add$0x28,%rsp
545- 3ce: c3 retq
546-
547-03cf :
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
-
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/
Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
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 - 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/
Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
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 <[EMAIL PROTECTED]> > > > > > > > > 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 <[EMAIL PROTECTED]> > > > > > > > > --- > > > > 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 - 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/
Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
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 <[EMAIL PROTECTED]> > > > > > > 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 <[EMAIL PROTECTED]> > > > > > > --- > > > 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 > - 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/
Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
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 <[EMAIL PROTECTED]> > > > > 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 <[EMAIL PROTECTED]> > > > > --- > > 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 - 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/
Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
* From: Denis Cheng
* Newsgroups: linux.kernel
* Date: Fri, 22 Jun 2007 22:15:49 -0700 (PDT)
> From: Denis Cheng <[EMAIL PROTECTED]>
>
> 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 <[EMAIL PROTECTED]>
>
> ---
> 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
-
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/
[PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
From: Denis Cheng <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
---
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 <[EMAIL PROTECTED]> 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.0 +0800
+++ arch/x86_64/mm/init.c 2007-06-23 13:12:26.0 +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;
-
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/
Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
On 6/19/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: Denis Cheng wrote: > From: Denis Cheng <[EMAIL PROTECTED]> > > 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 - 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/
Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
On Mon, Jun 18, 2007 at 10:07:21AM -0700, Jeremy Fitzhardinge wrote: > Denis Cheng wrote: > > From: Denis Cheng <[EMAIL PROTECTED]> > > > > 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 - 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/
Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
Denis Cheng wrote: > From: Denis Cheng <[EMAIL PROTECTED]> > > 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 - 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/
Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
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 <[EMAIL PROTECTED]>
>>
>> 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 <[EMAIL PROTECTED]>
>>
>> ---
>> Is there some comments on this?
>>
>> --- arch/x86_64/mm/init.c.orig 2007-06-07 10:08:04.0 +0800
>> +++ arch/x86_64/mm/init.c2007-06-18 14:43:15.0 +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!
-
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/
Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
On Mon, 18 Jun 2007, Denis Cheng wrote:
> From: Denis Cheng <[EMAIL PROTECTED]>
>
> 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 <[EMAIL PROTECTED]>
>
> ---
> Is there some comments on this?
>
> --- arch/x86_64/mm/init.c.orig2007-06-07 10:08:04.0 +0800
> +++ arch/x86_64/mm/init.c 2007-06-18 14:43:15.0 +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
-
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/
[PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
From: Denis Cheng <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
---
Is there some comments on this?
--- arch/x86_64/mm/init.c.orig 2007-06-07 10:08:04.0 +0800
+++ arch/x86_64/mm/init.c 2007-06-18 14:43:15.0 +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;
-
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/
