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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Jun 2007 00:25:18 +0200
From:	Oleg Verych <olecom@...wer.upol.cz>
To:	rae l <crquan@...il.com>
Cc:	trivial@...nel.org, linux-kernel@...r.kernel.org
Subject: 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 <olecom@...wer.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@...r.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/