x86, bitops: Change bitops to be native operand size
commit9b710506a03b01a9fdd83962912bc9d8237b82e8
authorH. Peter Anvin <hpa@linux.intel.com>
Tue, 16 Jul 2013 22:20:14 +0000 (16 15:20 -0700)
committerH. Peter Anvin <hpa@linux.intel.com>
Tue, 16 Jul 2013 22:24:04 +0000 (16 15:24 -0700)
treeffea830cd50ad9c51fff6128e1d2e09eef76e4ec
parent00e55a790706223c903ce6a450c18596a7bc9be0
x86, bitops: Change bitops to be native operand size

Change the bitops operation to be naturally "long", i.e. 63 bits on
the 64-bit kernel.  Additional bugs are likely to crop up in the
future.

We already have bugs which machines with > 16 TiB of memory in a
single node, as can happen if memory is interleaved.  The x86 bitop
operations take a signed index, so using an unsigned type is not an
option.

Jim Kukunas measured the effect of this patch on kernel size: it adds
2779 bytes to the allyesconfig kernel.  Some of that probably could be
elided by replacing the inline functions with macros which select the
32-bit type if the index is a 32-bit value, something like:

In that case we could also use "Jr" constraints for the 64-bit
version.

However, this would more than double the amount of code for a
relatively small gain.

Note that we can't use ilog2() for _BITOPS_LONG_SHIFT, as that causes
a recursive header inclusion problem.

The change to constant_test_bit() should both generate better code and
give correct result for negative bit indicies.  As previously written
the compiler had to generate extra code to create the proper wrong
result for negative values.

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Jim Kukunas <james.t.kukunas@intel.com>
Link: http://lkml.kernel.org/n/tip-z61ofiwe90xeyb461o72h8ya@git.kernel.org
arch/x86/include/asm/bitops.h
arch/x86/include/asm/sync_bitops.h