e4afd2e556
lib/find_bit.c: micro-optimise find_next_*_bit
...
This saves 32 bytes on my x86-64 build, mostly due to alignment
considerations and sharing more code between find_next_bit and
find_next_zero_bit, but it does save a couple of instructions.
There's really two parts to this commit:
- First, the first half of the test: (!nbits || start >= nbits) is
trivially a subset of the second half, since nbits and start are both
unsigned
- Second, while looking at the disassembly, I noticed that GCC was
predicting the branch taken. Since this is a failure case, it's
clearly the less likely of the two branches, so add an unlikely() to
override GCC's heuristics.
[mawilcox@microsoft.com: v2]
Link: http://lkml.kernel.org/r/1483709016-1834-1-git-send-email-mawilcox@linuxonhyperv.com
Link: http://lkml.kernel.org/r/1483709016-1834-1-git-send-email-mawilcox@linuxonhyperv.com
Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com >
Acked-by: Yury Norov <ynorov@caviumnetworks.com >
Acked-by: Rasmus Villemoes <linux@rasmusvillemoes.dk >
Signed-off-by: Andrew Morton <akpm@linux-foundation.org >
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org >
2017-02-24 17:46:57 -08:00
552eb975b8
tools lib: Move find_next_bit.c to tools/lib/
...
The commit that introduced it should've moved it to the same place, plus
the 'tools/' prefix, but instead moved it to a bogus tools/lib/util/
directory, being the only file there.
Move it to tools/lib/find_bit.c, picking the name for the file where
these routines live since:
8f6f19dd51adrian.hunter@intel.com >
Cc: Borislav Petkov <bp@suse.de >
Cc: David Ahern <dsahern@gmail.com >
Cc: George Spelvin <linux@horizon.com
Cc: Jiri Olsa <jolsa@redhat.com >
Cc: Namhyung Kim <namhyung@kernel.org >
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk >
Cc: Wang Nan <wangnan0@huawei.com >
Cc: Yury Norov <yury.norov@gmail.com >
Link: http://lkml.kernel.org/n/tip-p391cex5mqvahp4pwrton87n@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com >
2016-01-08 12:35:35 -03:00
