Tested code generation (gcc (GCC) 3.2.2 20030222) and the optimization 
for powers of two works.  Reassigning base to a register causes the 
builtin_constant check to be dropped, but since these are constants 
anyway we can reference base without side effects.  I didn't extract n 
into a register to avoid side effects if it was not already done, since 
there are several possible places where the macro can generate side 
effects for (n) and even a comment to this effect.

This does the right thing for at least i386 and the generic code, and 
generates the expected shifts and and masks for power of two divides.

I'm compiling and booting a kernel now to make sure it really works, but 
the assembler looks great.  Apologies if I broke any other 
architectures, but it's quite difficult to test them all, and the non-ws 
code change is minimal

Zachary Amsden
zach@vmware.com

Linus Torvalds wrote:

>On Wed, 27 Oct 2004, Zachary Amsden wrote:
>  
>
>>I noticed several 64-bit divides for HZ/USER_HZ, and also the fact that 
>>HZ == USER_HZ on many architectures (or if you play with scaling it ;).  
>>Since do_div is macroized to optimized assembler on many platforms, we 
>>emit long divides for divide by one.  This could be extended further to 
>>recognize other power of two divides, but I don't think the complexity 
>>of the macros would be justified.  I also didn't feel it was worthwhile 
>>to optimize this for non-constant divides; if you feel otherwise, please 
>>extend.
>>    
>>
>
>Can you test out the trivial extension, which is to allow any power-of-two
>constant, and just leave it as a divide in those cases (and let the
>compiler turn it into a 64-bit shift)?
>
>It's very easy to test for powers of two: !((x) & ((x)-1)) does it for 
>everything but zero, and zero in this case is an error anyway.
>
>		Linus
>  
>