zstd: Make load(32|64)32 safer and smaller

[greatroar]

load3232 and load6432 now limit their slice to its length. This improves safety, since encoders can no longer look at the part beyond the length. It also produces several dozen fewer instructions for bounds checks.

[klauspost]

@greatroar Great. Could you double check that times are same or better?

[greatroar]

name                                 old speed      new speed      delta
Encoder_EncodeAllXML-8                283MB/s ± 1%   281MB/s ± 1%     ~     (p=0.053 n=9+9)
Encoder_EncodeAllSimple/fastest-8     111MB/s ± 0%   113MB/s ± 0%   +2.06%  (p=0.000 n=9+10)
Encoder_EncodeAllSimple/default-8    78.8MB/s ± 0%  79.3MB/s ± 0%   +0.70%  (p=0.000 n=10+9)
Encoder_EncodeAllSimple/better-8     65.0MB/s ± 1%  66.1MB/s ± 0%   +1.70%  (p=0.000 n=10+9)
Encoder_EncodeAllSimple/best-8       16.5MB/s ± 7%  17.1MB/s ± 2%   +4.01%  (p=0.000 n=10+10)
Encoder_EncodeAllSimple4K/fastest-8   919MB/s ± 1%   905MB/s ± 1%   -1.48%  (p=0.000 n=10+10)
Encoder_EncodeAllSimple4K/default-8  74.8MB/s ± 1%  74.8MB/s ± 1%     ~     (p=0.755 n=10+10)
Encoder_EncodeAllSimple4K/better-8   60.0MB/s ± 3%  62.7MB/s ± 1%   +4.48%  (p=0.000 n=10+10)
Encoder_EncodeAllSimple4K/best-8     14.8MB/s ± 2%  14.8MB/s ± 2%     ~     (p=0.810 n=10+10)
Encoder_EncodeAllHTML-8               133MB/s ± 1%   134MB/s ± 1%   +0.75%  (p=0.000 n=10+10)
Encoder_EncodeAllTwain-8             86.2MB/s ± 1%  85.7MB/s ± 1%   -0.53%  (p=0.012 n=10+10)
Encoder_EncodeAllPi-8                63.8MB/s ± 0%  63.8MB/s ± 1%     ~     (p=0.542 n=10+10)
[Geo mean]                           83.7MB/s       84.4MB/s        +0.90%

[klauspost]

okie. I don't really see how it produces several dozen fewer instructions for bounds check:

before:

	0x014e 00334 (zstd\zstd.go:135)	MOVLQSX	R11, AX
	0x0151 00337 (zstd\zstd.go:135)	CMPQ	CX, AX
	0x0154 00340 (zstd\zstd.go:135)	JCS	5832
	0x015a 00346 (zstd\zstd.go:135)	PCDATA	$1, $-1
	0x015a 00346 (<unknown line number>)	NOP
	0x015a 00346 (zstd\zstd.go:135)	MOVQ	CX, R12
	0x015d 00349 (zstd\zstd.go:135)	SUBQ	AX, CX
	0x0160 00352 (zstd\zstd.go:135)	MOVQ	AX, R13
	0x0163 00355 (zstd\zstd.go:135)	SUBQ	R9, AX
	0x0166 00358 (zstd\zstd.go:135)	SARQ	$63, AX
	0x016a 00362 (zstd\zstd.go:135)	ANDQ	AX, R13
	0x016d 00365 ($GOROOT\src\encoding\binary\binary.go:102)	CMPQ	CX, $7
	0x0171 00369 ($GOROOT\src\encoding\binary\binary.go:102)	JLS	5822

after:

	0x014e 00334 (zstd\zstd.go:135)	MOVLQSX	R11, AX
	0x0151 00337 (zstd\zstd.go:135)	CMPQ	CX, AX
	0x0154 00340 (zstd\zstd.go:135)	JCS	5765
	0x015a 00346 (zstd\zstd.go:135)	PCDATA	$1, $-1
	0x015a 00346 (<unknown line number>)	NOP
	0x015a 00346 (zstd\zstd.go:135)	MOVQ	CX, R12
	0x015d 00349 (zstd\zstd.go:135)	SUBQ	AX, CX
	0x0160 00352 (zstd\zstd.go:135)	MOVQ	CX, R13
	0x0163 00355 (zstd\zstd.go:135)	NEGQ	CX
	0x0166 00358 (zstd\zstd.go:135)	SARQ	$63, CX
	0x016a 00362 (zstd\zstd.go:135)	ANDQ	CX, AX
	0x016d 00365 ($GOROOT\src\encoding\binary\binary.go:102)	CMPQ	R13, $7
	0x0171 00369 ($GOROOT\src\encoding\binary\binary.go:102)	JLS	5752

Seems like a SUBQ was replaced by a NEGQ - same latency and throughput.

But as long as it isn't worse it's fine. Just want to know what to expect.

[greatroar]

Inlining is key. E.g. in

compress/zstd/enc_best.go

Line 315 in 2f99358

nextHashL := hashLen(load6432(src, sAt), bestLongTableBits, bestLongLen)

the inlined load6432 previously had to fetch both len(src) and cap(src) from the stack to do the bounds check. It now only needs the length.