The inner loop in f still has writes in it, which is probably why it is slower than g (whose inner loop is completely in registers).

To fix this I think we'd have to promote t.x from memory to register somehow. That seems pretty challenging.
(If the loop were unrolled it might get much of that effect automatically.)

The problem also exists for reads:

package pointers

import "testing"

const N = 1000
var a [N]int
var r int

//go:noinline
func g1(a *[N]int) int {
	var r int
	_ = *a
	for i := range a {
		r += a[i]
	}
	return r
}

//go:noinline
func g0(a *[N]int) int {
	var r int
	for i := range a {
		r += a[i]
	}
	return r
}

func Benchmark_g1(b *testing.B) {
	for i := 0; i < b.N; i++ { r = g1(&a) }
}

func Benchmark_g0(b *testing.B) {
	for i := 0; i < b.N; i++ { r = g0(&a) }
}

Benchmark_g1-4   	 2178316	       556.8 ns/op
Benchmark_g0-4   	 1949654	       611.8 ns/op

It looks the read case is different from the write case. The compiler generates one more instruction TESTB AL, (AX) for the g0 function in the read case.

@go101 In your example it's just that the nil pointer check is outside the loop in g1 but inside the loop in g0. We'd need to lift the nil check out of the loop to make them the same speed. Which I believe is #41666.