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
| ||
|
Date: Tue, 15 Sep 2020 01:31:50 +0100 From: Al Viro <viro@...iv.linux.org.uk> To: mateusznosek0@...il.com Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [RFC PATCH] fs: micro-optimization remove branches by adjusting flag values On Mon, Sep 14, 2020 at 07:43:38PM +0200, mateusznosek0@...il.com wrote: > From: Mateusz Nosek <mateusznosek0@...il.com> > > When flags A and B have equal values than the following code > > if(flags1 & A) > flags2 |= B; > > is equivalent to > > flags2 |= (flags1 & A); > > The latter code should generate less instructions and be faster as one > branch is omitted in it. > > Introduced patch changes the value of 'LOOKUP_EMPTY' and makes it equal > to the value of 'AT_EMPTY_PATH'. Thanks to that, few branches can be > changed in a way showed above which improves both performance and the > size of the code. No. AT_EMPTY_PATH is a part of userland ABI; to tie LOOKUP_EMPTY to it means that we can't ever modify the sucker. Worse, it restricts any possible reshuffling of the LOOKUP_... bits in the future. So unless you can show an effect on the real-world profiles, there are fairly strong reasons to avoid that headache.
Powered by blists - more mailing lists