Re: [PATCH] speed up on find_first_bit for i386 (let compiler dothe work)

From: Linus Torvalds
Date: Fri Jul 29 2005 - 11:33:31 EST

On Fri, 29 Jul 2005, Maciej W. Rozycki wrote:
> Hmm, that's what's in the GCC info pages for the relevant functions
> (I've omitted the "l" and "ll" variants):
> "-- Built-in Function: int __builtin_ffs (unsigned int x)
> Returns one plus the index of the least significant 1-bit of X, or
> if X is zero, returns zero.

This, for example, clashes with the x86 semantics.

If X is zero, the bsfl instruction will set the ZF flag, and the result is
undefined (on many, but not all, CPU's it will either be zero _or_

We don't care, since we actually test the input for being zero separately
_anyway_, but my point is that if the builtin is badly done (and I
wouldn't be in the least surprised if it was), then it's going to do a
totally unnecessary conditional jump of cmov.

See? __builtin's can generate _worse_ code, exactly because they try to
have portable semantics that may not even matter.

In contrast, just doing it by hand allows us to avoid all that crap.

Doing it by hand as inline assembly also allows us to do dynamic
optimizations like instruction rewriting, so inline assembly is a _lot_
more powerful than builtins can reasonably ever be.

> If that's not enough, then what would be? I'm serious -- if you find it
> inadequate, then perhaps it could be improved.

It's inadequate because IT IS POINTLESS.

The builtin buys you absolutely _nothing_, and the inline asm is simpler,
potentially faster, and works with every single version of gcc.


It has absolutely _zero_ upsides, and I've named three _major_ downsides.

It has another downside too: it's extra complexity and potential for bugs
in the compiler. And if you tell me gcc people never have bugs, I will
laugh in your general direction.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at