using gcc built-ins for bitops?

gcc 3.4 gained support for several typical bitops as builtin directives.
Using these over inline asm has a few advantages:
* gcc can optimize constants into these better
* gcc can reorder and schedule the code better
* gcc can allocate registers etc better for the code

The question is if we consider it desirable to go down this road or not. In order to help that discussion I've attached a patch below that switches the i386 ffz() function to the gcc builtin version, conditional on gcc having support for this. Before I go down the road of converting more functions and/or architectures.... is this worth doing?

+static inline unsigned long ffz (unsigned long word) +{
+ return __builtin_ctzl (~word);
+}

Quoted 1 line

and/or architectures.... is this worth doing?

I guess it depends on the resulting code size and quality. Some extra conversions would be needed for that.

For the implementation it would be nice to have the old-style implementations in one header and the new-style ones in a separate header. That would create a bit of an all-or-nothing situation, but that should be OK?

Perhaps. It's not impossible that say gcc 3.5 will add a few more builtins even that then allow more functions to be converted, otoh that shouldn't be impossible to cope with. I'll have a look to see how it pans out.

Quoted 7 lines · Arjan van de Ven

gcc 3.4 gained support for several typical bitops as builtin directives.
Using these over inline asm has a few advantages:
* gcc can optimize constants into these better
* gcc can reorder and schedule the code better
* gcc can allocate registers etc better for the code

Quoted 5 lines

The question is if we consider it desirable to go down this road or not. In order to help that discussion I've attached a patch below that switches the i386 ffz() function to the gcc builtin version, conditional on gcc having support for this. Before I go down the road of converting more functions and/or architectures.... is this worth doing?

I guess it depends on the resulting code size and quality. Some extra conversions would be needed for that.

For the implementation it would be nice to have the old-style implementations in one header and the new-style ones in a separate header. That would create a bit of an all-or-nothing situation, but that should be OK?

Quoted 4 lines · Andrew Morton

For the implementation it would be nice to have the old-style implementations in one header and the new-style ones in a separate header. That would create a bit of an all-or-nothing situation, but that should be OK?

In addition I stuck those in asm-generic since they no longer are architecture specific....

Quoted 6 lines · Arjan van de Ven

Quoted 4 lines · Andrew Morton

For the implementation it would be nice to have the old-style implementations in one header and the new-style ones in a separate header. That would create a bit of an all-or-nothing situation, but that should be OK?

Quoted 2 lines

In addition I stuck those in asm-generic since they no longer are architecture specific....

This is not going to work.
Say on x86_64, __builtin_ctzl (~word) ends up __ctzdi2 (~word) call in GCC 3.4.x, which is not defined in the kernel (in 3.5 it will be bsfq). On a bunch of arches which don't have an instruction for ffz operation it will always result in a library call.

It's actually fine; the architecture first needs to include this file and there it can use the proper ifdefs; the functions themselves don't matter, only when they can be used, and the arch still controls that.

I see a list of these gcc bitop builtins at the bottom of the page:

http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

Looks like you can find the position of the first 1 bit, the length of the leading or trailing seq of 0 bits, the hamming weight (popcount) and the parity, each for int, long and long long.

I just add this for the benefit of others.

As to your primary question - is this worth doing - I don't have an answer.

Quoted 3 lines

As to your primary question - is this worth doing - I don't have an answer.

It is, for 2 reasons:
1) unlike __asm, GCC knows how to schedule the instructions in the builtins
2) GCC will handle stuff like ffz (16) at compile time rather than runtime

Hi,

gcc 3.4 gained support for several typical bitops as builtin directives. Using these over inline asm has a few advantages:
* gcc can optimize constants into these better
* gcc can reorder and schedule the code better
* gcc can allocate registers etc better for the code

The question is if we consider it desirable to go down this road or not. In order to help that discussion I've attached a patch below that switches the i386 ffz() function to the gcc builtin version, conditional on gcc having support for this. Before I go down the road of converting more functions and/or architectures.... is this worth doing?

Greetings,
Arjan van de Ven

include/asm-i386/bitops.h renamed from include/asm-i386/bitops.h~ +8 -0

@@ -344,6 +344,8 @@
  *
  * Undefined if no zero exists, so code should check against ~0UL first.
  */
+ 
+#ifndef HAVE_BUILTIN_CTZL
 static inline unsigned long ffz(unsigned long word)
 {
 	__asm__("bsfl %1,%0"

@@ -351,6 +353,12 @@
 		:"r" (~word));
 	return word;
 }
+#else
+static inline unsigned long ffz (unsigned long word) 
+{ 
+	return __builtin_ctzl (~word); 
+}
+#endif
 
 /**
  * __ffs - find first bit in word.

include/linux/compiler-gcc3.h line 22

Quoted 7 lines

include/linux/compiler-gcc3.h renamed from include/linux/compiler-gcc3.h~ +1 -0

@@ -19,6 +19,11 @@
 # define __attribute_used__	__attribute__((__unused__))
 #endif
 
+#if __GNUC_MINOR__ >= 4

Please do no test only on minor. People have been arguing whether the next major release of GCC should be called 3.5 or 4.0 since tree-ssa has been merged.