linux-kernel - Re: [PATCH 2/3] Turn bitmap_set and bitmap

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] [day] [month] [year] [list]

Date:   Tue, 27 Jun 2017 09:58:52 +0200
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Matthew Wilcox <mawilcox@...rosoft.com>
Subject: Re: [PATCH 2/3] Turn bitmap_set and bitmap_clear into memset when possible

> It's actually slightly less efficient in the caller (although obviously
> memset() is going to execute faster than bitmap_set()).  Partly because
> x86 made some odd choices about the behaviour of an 8-bit move instruction
> (it leaves the upper 24 bits intact, rather than zeroing them, so gcc
> has to use a 32-bit move instruction to put 0xff into the second argument
> to memset()),

Heh, I thought gcc knew and made full use of the semantics of memset,
so that only the low byte matters. I suppose there might be
architectures where passing -1 is slightly cheaper (at least in code
size) than 255... [quick checking] indeed, on x86_64, there's no
change in the generated code, but on 32 bit, gcc ends up doing

6a ff                   push   $0xffffffff

instead of

68 ff 00 00 00          push   $0xff