Some comments, while I remember:

* the argument to _Py_HashPointer is not always divisible by 8.  It's
called to create hashes for various objects, including methodobjects; see 
the line:

	y = _Py_HashPointer((void*)(a->m_ml->ml_meth));

in meth_hash in methodobject.c, for example; here ml_meth is a C function 
pointer.  I can't see how this could be a problem, though, especially as 
is seems very unlikely that two function pointers could be less than 8 
bytes apart.

* following from the above, it's also pretty unlikely that any two object 
pointers will be less than 16 bytes apart, so it might be worth seeing if 
performance with >>4 is noticeably any different from with >>3.

* we should make sure that the value returned by _Py_HashPointer isn't the 
illegal hash value -1 (though it's difficult to see how it could be).  One 
safe way to do this that shouldn't cost any CPU cycles would be to cast to 
unsigned long before the right shift, to be sure that the right shift 
zero-extends instead of sign-extending, so that the result is guaranteed 
nonnegative.

* It *would* be nice to do something about the SIZEOF_LONG < SIZEOF_VOID_P 
case: the current conversion to a PyLong seems like quite an expensive way 
to go.  And I've just ordered a computer with 64-bit Windows installed...