Move division by 0 check out of the bloom loops

[StephenButtolph]

Why this should be merged

This PR provides hints to the compiler that numBits can be assumed to be non-zero when iterating over the bloom filter hashes.

The compiler requires these hints because there is a subtle change in behavior of the function if len(hashSeeds) == 0.

How this works

By including _ = 1 % numBits // hint to the compiler that numBits is not 0 outside of the loop we move the numBits == 0 division by 0 panic check outside of the loop.

We can see the difference in the compiled code of contains here (from go tool compile -S):

...
	PCDATA	$3, $1
	LSL	$3, R4, R2
+	CBZ	R2, $PANICDIVIDE
	MOVD	ZR, R5
	MOVD	$1, R7
	JMP	$LOOPCMP
UPDATEHASH:
	AND	$7, R8, R8
	MOVBU	(R3)(R9), R9
	LSR	R8, R9, R8
	ADD	$1, R5, R5
	AND	R8, R7, R7
LOOPCMP:
	CMP	R5, R1
	BLE	$EXIT
	MOVBU	R7, R8
	CBZW	R8, $EXIT
	MOVD	(R0)(R5<<3), R8
	EOR	R6@>47, R8, R6
-	CBZ	R2, $PANICDIVIDE
	UDIV	R2, R6, R8
	MSUB	R2, R6, R8, R8
	LSR	$3, R8, R9
	CMP	R8>>3, R4
	BHI	$UPDATEHASH
	JMP$PANICOOB
EXIT:
	MOVBU	R7, R1
	CMPW	$0, R1
	CSET	NE, R0
	LDP	-8(RSP), (R29, R30)
	ADD	$32, RSP
	RET	(R30)
PANICOOB:
	MOVD	R9, R0
	MOVD	R4, R1
	PCDATA	$1, $1
	CALL	runtime.panicIndexU(SB)
PANICDIVIDE:
	CALL	runtime.panicdivide(SB)
...

I wasn't able to figure out how to get the compiler to move the PANICOOB call out of the loop, which would further optimize the check.

How this was tested

Before:

BenchmarkAdd-12    		43385254	        27.47 ns/op	       0 B/op	       0 allocs/op
BenchmarkContains-12    	52014932	        22.85 ns/op	       0 B/op	       0 allocs/op

After:

BenchmarkAdd-12    		43245295	        27.08 ns/op	       0 B/op	       0 allocs/op
BenchmarkContains-12    	53046825	        22.50 ns/op	       0 B/op	       0 allocs/op

🚀

[aaronbuchwald]

Great meme