The duplicate bounds check is because it is reloading the length, and the length may have changed because you're reading from a global. It's reloading because the intermediate store/load of the float value is hiding the fact that the loads of the length can be combined.

The extraneous write/read problem is #13095. I'd rather fix that issue than intrinsify, if we can.

@nigeltao Could you take the address instead?

p := &u32Slice[0];
*p = math.Float32bits(1 + math.Float32frombits(*p))

Presumably this gives you just one index check.

@griesemer: yes, that gives me just one index check.

Feel free to punt to Unplanned if you think this isn't worth doing any time soon.

Was this fixed by CL 58732?

This appears at least partially fixed by CL 58732. There are still some issues :(

package foo

import "math"

var f []float32
var u []uint32

func a(f *float32) {
	*f = *f + 1
}
func b(u *uint32) {
	*u = *u + 1
}

func c(u *uint32) {
	*u = math.Float32bits(1 + math.Float32frombits(*u))
}

func d(f *float32) {
	*f = math.Float32frombits(1 + math.Float32bits(*f))
}

"".a STEXT nosplit size=22 args=0x8 locals=0x0
        0x0000 00000 (tmp.go:8)   MOVSS   $f32.3f800000(SB), X0
        0x0008 00008 (tmp.go:8)   MOVQ    "".f+8(SP), AX
        0x000d 00013 (tmp.go:9)   ADDSS   (AX), X0
        0x0011 00017 (tmp.go:9)   MOVSS   X0, (AX)
        0x0015 00021 (tmp.go:10)  RET
"".b STEXT nosplit size=8 args=0x8 locals=0x0
        0x0000 00000 (tmp.go:11)  MOVQ    "".u+8(SP), AX
        0x0005 00005 (tmp.go:12)  INCL    (AX)
        0x0007 00007 (tmp.go:13)  RET
"".c STEXT nosplit size=28 args=0x8 locals=0x0
        0x0000 00000 (tmp.go:15)  MOVQ    "".u+8(SP), AX
        0x0005 00005 (tmp.go:16)  MOVL    (AX), CX
        0x0007 00007 (tmp.go:16)  MOVL    CX, X0
        0x000b 00011 (tmp.go:16)  MOVSS   $f32.3f800000(SB), X1
        0x0013 00019 (tmp.go:16)  ADDSS   X0, X1
        0x0017 00023 (tmp.go:16)  MOVSS   X1, (AX)
        0x001b 00027 (tmp.go:17)  RET
"".d STEXT nosplit size=18 args=0x8 locals=0x0
        0x0000 00000 (tmp.go:19)  MOVQ    "".f+8(SP), AX
        0x0005 00005 (tmp.go:20)  MOVSS   (AX), X0
        0x0009 00009 (tmp.go:20)  MOVL    X0, CX
        0x000d 00013 (tmp.go:20)  INCL    CX
        0x000f 00015 (tmp.go:20)  MOVL    CX, (AX)
        0x0011 00017 (tmp.go:21)  RET

On the plus side, c and d do the direct store without any need for conversion.
On the minus side, c and d do a load+convert instead of loading to the target register type directly.
I'll see if I can fix that.

Fixing this is tricky. There's a phase ordering problem.
When you have a load/convert sequence, you'd like to rewrite it to just a load of the converted type. That rewrite is only safe if the load has only one use. (Otherwise you're replacing one source load with two generated loads, and that's not ok.) In the cases here, during rewrite there are 2 uses of the load. There's the convert op, but also the store to the (eventually unused) stack temp. We don't know that second use is going to go away until after we remove unread temps, and that doesn't happen until rewrites are done.

That rewrite is only safe if the load has only one use. (Otherwise you're replacing one source load with two generated loads, and that's not ok.)

Out of curiosity why isn't that ok? From a performance perspective I would have thought that issuing two loads might be better than a load followed by a move (easier to schedule). Are there other limitations?

We have to be careful that we don't break code that does something like:

   x := *p
   y := x - x

We want to guarantee that y is always zero, even in the presence of races.

I think the language spec doesn't require this, but as a practical matter we have to. I allowed this by accident once, and I broke sync.Mutex.Lock. It does essentially

old := m.state
if old & mask == value {
    atomic.CompareAndSwap(&m.state, old, new)
}

If we allowed the m.state load to happen twice instead of once, then the two values of old can be different, and bad things happen.