This is actually more than a performance bug. The nil checks are not getting scheduled correctly.

func f(p *[1e6]*int) int {
	return *p[1e4]
}

This compiles to

		MOVQ	"".p+8(SP), AX
		MOVQ	80000(AX), CX
		TESTB	AL, (AX)
		MOVQ	(CX), AX
		MOVQ	AX, "".~r1+16(SP)
		RET

The read is happening before its corresponding nil check. The nil check elim pass is doing the right thing. It is the scheduling pass which is wrong.

I don't see an obvious way to defeat type safety with this bug, but it makes me nervous. We should fix it for 1.16.

Change https://golang.org/cl/270940 mentions this issue: cmd/compile: improve scheduling pass

This is looking trickier than first appears (see CL). I'm going to punt to 1.17.

I think the worst thing that can happen here is that we can read arbitrary parts of memory before a nil fault. In those cases it was going to fault anyway, so maybe we get a SIGBUS instead of a SIGSEGV. That's about as bad as it gets. Perhaps memory-mapped device drivers might treat reads as having side-effects, but that seems like a tiny attack surface.

Possibly also there's some spectre-ish vulnerability here, but without the speculation, if a chain of nilptr-delayed reads can be constructed. I think it would involve some very strange gadgets that would have to be in a binary, though, so it appears unlikely to matter.

Is this going to happen for 1.17? Thanks.

No, it is not. I have a CL but it isn't quite right - it needs more tweaking.

@randall77 This has been rolling forward through milestones. Should it move to Backlog?

No, let's just punt this to 1.20. I have some ideas on how to fix, just need to make them happen.

Bumping to 1.21. I actually have a CL stack that will fix this in the next release. CL 270940.